High5
/
vi
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Commit archive

This commit is contained in:
mischa 2024-06-16 21:59:42 +02:00
commit 8d6e68fc21
218 changed files with 17071 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

162
HELP Normal file
View File

@ -0,0 +1,162 @@
HELP ON USING THE MAIL INTERFACE AT VI/EX ARCHIVE alf.uib.no
************************************************************
BEWARE: If you have anon. ftp capability, please use that instead of
this mailserver (see below).
VI/EX Archive alf.uib.no, and its mirrors have the most complete, and
the biggest publically available archive containing VI/EX stuff.
To access the mailer, just send a mail message to ruben@uib.no.
You have two ways of fetching files:
1) Single file.
2) Multiple files.
Single file request
~~~~~~~~~~~~~~~~~~~
In the Subject field in your header of your message you simply put
GET <filename>.
Example of a simple request to get the INDEX file:
unix% or:
unix% mail ruben@uib.no To: ruben@uib.no
Subject: GET INDEX Subject: GET INDEX
.
unix%
Multiple file request
~~~~~~~~~~~~~~~~~~~~~
In the Subject field in your header put MULTIGET or MGET.
Then in your message you put several GET <filename>.
Example of a multiple file request:
unix% or:
unix% mail ruben@uib.no To: ruben@uib.no
Subject: MULTIGET Subject: MULTIGET
GET INDEX GET INDEX
GET HELP GET HELP
GET macros/ctags.Z GET macros/ctags.Z
.
unix%
The old Mailserver did send a Control File for each file requested. This
is not so anymore. Now the Controll information will be embedded into the
message itself.
DO NOT request the whole archive! If you request the whole archive all
at one time I will report you to your site admin. There is a limit of
10 files in a MULTIGET.
If you do want the whole archive, please contact me first and we will
work out something.
Before fetching a file, think: "Do I realy need this file, or is it just
'nice to have it' ?"
Most files will be run thru uuencode (1) before mailng, even textfiles.
To extract a requested file, use the command uudecode (1).
If you do not get a reply within a reasonable time, please do not send
another request for the file(s).
Please report any problems or question to ruben@uib.no. But remeber to
never put "GET" or "MGET" or "MULTIGET" in the Subject of the message.
Rather put in "Mailserver problem", if I'm online I will get a imediate
notification that such message is in my mail-bucket.
A lot of my mail are simply put into the bucket without imediate action.
FTP:
Remeber that those who allow anon-ftp are very kind. Please do not
misuse or abuse this privilege.
Think twice before downloading, esp if you are a long-distance ftp' er.
If you are going to use FTP, use the site that is the closest to you
counting NET-VICE. If you don't know what I'm talking about, please
ask someone who does (like your system administrator).
IF YOU HAVE FTP-ACCESS, DO *NOT* USE THE MAILSERVER. Not even if you
temporarily cannot reach alf.uib.no or its mirrors.
The mirroring sites are always promptly updated.
Why YOU shold use the site closest to you NET-VICE:
- Faster access.
- Reducing the net load.
- Keeping the site on the net.
The main archive is in Bergen, Norway, EUROPE.
alf.uib.no is mirrored at sites around the world. If you find a
site nearer to you than alf.uib.no, please use that site.
The mirroing sites are ALWAYS updated.
Please do NOT use ftp to the sites during peak hours at the various
locations. Please respect this because if there is too much ftp'ing
going on in prime time to the various places, the ftp site may have to
shut down. NONE OF US WOULD WANT THAT, WOULD WE ?
The following sites contains the VI/EX archives:
European users:
Main site: alf.uib.no (129.177.30.3)
Filearea: pub/vi
Maintainer: Ove Ruben R Olsen (buboo@alf.uib.no)
Location: Bergen, Norway, EUROPE.
Peak hours: 07.00 am GMT to 03.00 pm GMT
Japanese users:
Mirror site: utsun.s.u-tokyo.ac.jp (133.11.11.11)
Filearea: misc/vi
Maintainer: Eric E. Bowles (bowles@utsun.s.u-tokyo.ac.jp)
Location: Tokyo, Japan, ASIA.
Peak hours: 01.00 am GMT to 09.00 am GMT
USA, Canada and Mexican users:
Mirror site: cs.uwp.edu (131.210.1.4)
Filearea: /pub/vi
Maintainer: Dave Datta (datta@cs.uwp.edu)
Location: Kenosha, Wisconsin, U.S.A.
Peak hours: None.
Mirror site: ftp.uu.net (192.48.96.9)
Filearea: /pub/text-processing/vi
Maintainer: archive@uunet.uu.net
Location: Falls Church, Virginia, U.S.A.
Peak hours: None.
Australia, NZ and the rest Down Under:
Main site: monu6.cc.monash.edu.au (130.194.1.106)
Filearea: /pub/vi
Maintainer: Steve Balogh (steve@monash.edu.au)
Location: Melbourne, AUSTRALIA.
Peak hours: Not relevent
This site is listed here for convinience to those who do not have
an Inet link, but do subscribe to GEnie.
GEnie (General Electric Network for Information Exchange):
Mirror site: Ultimate archive
Filearea: GEnie Unix RoundTable, library 11: Editors
Maintainer: GEnie mail=GARS
Location: Rockville, Maryland, U.S.A.
Peak hours: Available 24 hours but connect charges are reduced
from 1800 until 0800 local connect time (international
connect subject to PDN tarriffs)
Add. info.: Maint. may be contacted at (01) 501-227-7817
Gary Smith / P. O. Drawer 7680 / Little Rock, AR 72217
CONTRIBUTION:
If you have stuff about ex/vi, macros, tips and tricks, please email it to
ruben@uib.no or inclusion in this archive.
Regards,
Ove Ruben R Olsen
VI/EX Archive maintainer.

298
INDEX Normal file
View File

@ -0,0 +1,298 @@
#
# Index of archive: alf.uib.no (129.177.30.3)
# Filearea: /pub/vi
# Archive maintainer: Ove Ruben R Olsen ruben@uib.no
# Archive updated: Sat May 20 11:55:33 GMT 1995
# Mirroring archives: utsun.s.u-tokyo.ac.jp (133.11.11.11)
# cs.uwp.edu (131.210.1.4)
# ftp.uu.net (192.48.96.9)
# monu6.cc.monash.edu.au (130.194.1.106)
#
If one of the mirror-archives are closer to you, plase get the files
from there.
There are 4 directories:
docs - Documentation on VI, also some comp.editors postings
macros - VI macros
comp.editors - Various materials posted to comp.editors
programs - VI's for various platforms (and programs).
UCB = University of California, Berkley. (Hometown of vi)
CED = Comp.editors discussion/article in NetNews.
################################################################################
DIRECTORY: pub/vi/
INDEX This file.
HELP Help file for the Emailserver.
POINTERS Pointers to other interesting stuff. (VI resemblence).
WHO A 'thank you' too all who have submitted to the archive.
comp.editors.ARC Comp.Editors FAQ VI/EX archivelist.
comp.editors.EDS Comp.Editors FAQ list of editors.
comp.editors.FAQ Comp.Editors FAQ.
comp.editors2 The other file posted to comp.editors once in a while.
comp.editors3 Standard reply for info. requests on C.E.
################################################################################
DIRECTORY: pub/vi/docs
8bit.Z CED: 8 bit clean implies what?
advocasy.Z Advocating VI by Martin Weitzel.
apwh.ms.Z VI Command & Function Reference. UCB-dist.
arrowkeys.Z Arrow keys in VI.
bed.tar.Z A frontend to VI for edtiting binary files. Version: 1.0
beginers.Z VI beginers guide.
books.Z A short note on books on VI.
bugs.Z Bugs and explanation of those.
capitalize.Z Capitalizing first [a-z] letter in sentence in vi
card.tex.Z VI reference card in TeX. Found inside learn-vi.tar.Z
caseconv.Z Converting Proper case to Upper case in Vi.
casesr.Z Changing case during search and replace in VI.
chars.Z Appendix: character functions. UCB-dist. A Must.
chars.tex.Z A \LaTeX fyed version of vi.chars.Z. Maurizio Codogno.
ckv.Z Diary/Log editing and C-programming.
ckv2.Z RCS-maintaining and Shell programing.
course.Z A course on using VI. Paper.
course.tar.Z A course package on using VI. Paper.
crypt.Z Tips and macros on handling crypted files/mail. M. Wyle.
ctags.Z Various stuff about Ctags and VI.
e2.tar.Z A File history interface. A must. Version: 1.3
editech.1.Z General techiques on editor implementation.
editech.2.Z Updating the screen in a buffer-gap editor.
editech.3.Z How to 'store' the file in memory. Buffer GAP method.
editech.4.Z Buffer management in the Poplog editor VED.
editech.5.Z Questions (and answers) about buffer-gap implementations.
editech.books.Z Information on writing text editors
elvis.Z Laitest ELVIS (1.5) doc - The VI clone that run on most OS.
ex.changes.Z EX changes from version to version. UCB-dist.
ex.fix.Z An Encore EX fix.
ex.reference.Z EX Reference Manual. UCB-dist. A Must.
ex.summary.Z EX Command Summary. UCB-dist.
formating.Z Textformating inside vi wiht or without external program.
globaldelete.Z :g/string/d in macro buffer !working
help.Z VI recerence card. Found inside learn-vi.tar.Z
innforing.Z A NORWEGIAN introduction to VI. Version 1.3-160.
intro.Z Introduction on Display Editing with VI. UCB-dist. A Must.
intro.ps.Z vi.intro in PostScript format. UCB-dist.
jl.ex.ref.Z Another reference for VI.
keybind.Z Tips on binding keys (map/map!). CED -posting.
keymapings.Z About key-mappings.
keys.Z What key's to map in VI. Table. Followed by a CED.
love.Z A colletions of "Why do you love vi ?" from comp.editors.
lvi.tar.Z The Learners Introduction to VI. Interactive. Bo Thide.
macroDoc.tar.Z Two docs describing macros in VI. Sample exrc file incl.
macros.Z Macros, Abbrevitations, and Buffers.
macrotips.Z Various macrotips.
man.tut.Z VI manual-page with a tutor.
mks.ant.Z Tips on macros in the MKS version of VI. Anthony C Howe.
motd.tar.Z Global /etc/motd file editor.
move.Z Hints file: Move Text from One File to Another. Dr. L. Leff
multfile.Z A doc on how to work with multiple files in VI.
mvi.c.Z Direcotry utility using VI.
nvi.tar.Z Novice VI. Bo Thide.
online-200.tar.Z VI ON-LINE HELP with 'windows for vi'. Version 2.00
passwd.Z A script for "secure" editing of /etc/passwd.
passwd.fix.Z A fix to vi.passwd.fix.Z
patch.Z Patch to fix a "security" hole in VI.
quick.Z VI Quick reference card.
rcut.tar.Z Rectangular cut and paste for VI. Robert Colon. Good.
ref.Z UNIX VI quick reference card.
refchrt.Z VI reference chart.
reference.Z VI reference. Version 8. Maarten Litmaath. A Must.
reference.ms.Z VI reference for typesetters.
sections.Z Sections in VI.
shell-101.BetaA.Z Conversion table between different shells.
sigint.fix.Z A src fix for VI dealing with 'sigint'.
song.Z A song about VI.
ss.qrf.Z Super Short quick reference card. Fits on a 80x24 screen.
summary.Z VI / EX Quick reference. UCB-dist.
tabd.Z Tabs and Blanks - Infavor of 8 column tabs. John E. Davis
tagStack.Z Patch for vaxen to make tag stack avail. Fixes for sun.
tags.Z A paper on a tag-technique. Using tags like macros.
terse.help.Z Extremely terse VI reference notes. Michael A. Crowley
tips.Z Beginer's tips on VI.
tutor.Z The tutor-file from vi.tutor.tar.Z (tutor.vi).
tutor.tar.Z An interactive tutor for VI. (Ver: 1.3) Beginner's choice.
tutor.tex.Z A exellent documet to use with vi.tutor.Z. Beginner's choice
ucb.tar.Z* The whole UCB-dist package.
vi.1.Z VI formated help manual. BEWARE: Not a "real" manual.
vifs.tar.Z Edit-file stack. CTAGS and VI effectively. Seigo Fujii. CED
vilearn.tar.Z A interactive VI tutorial in 5 movements.
vms.Z Information about VI for the VMS environment (DEC-VAX).
* DO *_N_O_T_* try to fetch this file via the Email interface. Most UUCP
mailers do NOT like files with more than 100000 bytes. A uuencoded version
of this file is 2833 lines long and 175445 bytes big. The contenst of this
tar archive is spread around as several files. I will under NO circumstances
ever implement a mail spliting in the mailserver. I have other more usefull
things to do.
Beginner's in VI should fetch the following files
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The following is a 'must' for starters:
intro.Z Introduction on Display Editing with VI. UCB-dist. A Must.
reference.Z VI reference. Version 8. Maarten Litmaath. A Must.
beginers.Z VI beginers guide.
tutor.Z The tutor-file from vi.tutor.tar.Z (tutor.vi).
card.tex.Z VI reference card in TeX. Found inside learn-vi.tar.Z
tutor.Z The tutor-file from vi.tutor.tar.Z (tutor.vi).
################################################################################
DIRECTORY: pub/vi/macros
README - A readmefile about the macros in this archive.
ball.tar.Z - Bouncing ball macro. Gadepalli, Balu, Subramanian.
blocks - Block- delte, move and copy. Sep 24 1991. Geoff Clare.
blocks.d.Z - Explanation of the blocks-macros. Sep 24 1991.
c.template.Z - Vi C-mode. Mitchell Wyle.
case - Convert case on word/line. * Bryan Ewbank.
case.word - Another word-case converter... Bryan Ewbank.
case.word2 - An improved case.word. * Jon Eiseman.
cases.d.Z - CED about vi and caseconversions.
caseword - Convert case on word. Eelco van Asperen.
center - Center text, spell check. Dave Beyerl.
cil.tc - Comment, Invert, Lint. Tom Christiansen.
cmacros - Small and quick C-macros. CED.
commentC.tar.Z - Very good way to do C-comments. Rob Hutten.
complete - Word completions using CTRL-Keys. E. Bowles.
complete.ext - Some extensions to 'complete'
complete.new - New version of complete.
cvi.Z - C Syntax Sensitive editing. Bo Thide.
emacs.style - Emacs style editing. Steve Kinzler.
evi.tar.Z - Full Blown Emacs emulator. Bo Thide.
execute - Easy way to execute exsternal commands. Stephen Reihm.
exrc.ach - "The Super .exrc File" compiled by Anthony C Howe.
exrc.brp - A nice exrc file from Bill "Rock" Petro.
fill - An easy way to fill a paragraph. Seigo Fujii.
fold.tar.Z - A folding package E. Bowles..
folding - The macro from folding.d.Z.
folding.d.Z - CED about "fold-editing" with vi.
generals - General, text, mail, C, Modula-2. Compiled by M. Lamoureux
generals.2 - EXRC and Pascal. Bradford L Knowles.
goodies.tar.Z - Find prev word, emacs-mode, C-mode and others. M. Neitzel.
hanoi - VI solves the infamous 'Towers of hanoi'. Greg McFarlane.
ispell - Spellcheckig for VI with ispell. Philip Kizer.
jl.ex - Some 'beginer' macros. Joel Loo Peing Ling.
latex - Latex mode. (Wery few, but promising) Mitchell Wyle.
latex2 - Latex mode. Oeyvind Flaam.
mail.enc.Z - Working with encrypted mail. Good. Mitchell Wyle.
man - Manpage lookup. Untested.
markring - Marking places in the text the easy way. Daniel Smith.
maze.tar.Z - Maze solving with vi. Greg McFarlane.
modula2 - Modula-2 macro package. Mitchell Wyle.
modula2.new - Modula-2 macro package. Roland Bickel.
morse - Write morsekode. Hugh McGuinness.
mymorse - Exchangement to 'morse'. No map!ings of lowercase.
pascal - Pascal mode. {\O}yvind Brusevold.
perl - Perl mode. Kenneth C Rich.
rcs - RCS vi macros. Phil Male.
ruler - Rulermacro. Bill Petro.
srm - Search and Replace macro. Very HEAVY stuff.. :-) D Wallach
turing.tar.Z - A turing machine with vi. Dave Hitz.
upcase - Turn your last typed word in to uppercase letters. L. Quin.
vogel.tar.Z - The Karl Vogel collection. Cmode. Logfile. SHmode. RSChelp.
wordsearch - Macro from wordsearch.d.Z. Elliott C Winslow.
wordsearch.d.Z - CED about searching for word under cursor.
ws - Word Star emulator. Version 0.00. Ove Ruben R Olsen.
* I have not got this to work.
################################################################################
DIRECTORY: /pub/vi/comp.editors
8bit.Z CED: 8 bit clean implies what?
append.Z Appending to external file with vi.
blankline.Z Removing / inserting blank lines in vi
blockdel.Z Deleting a block of text
blocks.Z Macros for block copy/move
buffer.Z View Content of Buffer
buffera.Z Clearing anon vi buffers (in Elvis) using :e command.
ced.tips.1.Z Comp.Editors tips collection. October 91 issue.
ced.tips.2.Z Comp.Editors tips collection. November 91 issue.
ced.tips.3.Z Comp.Editors tips collection. December 91 issue.
ced.tips.4.Z Comp.Editors tips collection. January 92 issue.
ced.tips.5.Z Comp.Editors tips collection. February 92 issue.
ced.tips.6.Z Comp.Editors tips collection. March 92 issue.
ced.tips.7.Z Comp.Editors tips collection. April 92 issue.
ced.tips.Inx.Z Comp.Editors tips collections INDEX file.
cmdline.Z EX-mode command line editing in vi
cols.Z Switching cols in VI
columedit.Z Using vi to edit columns
counter.Z Counter in VI
countwords.Z How to count words
crlf.Z How do I remove new-lines [CR,LF] in vi ?
cshline.Z A csh command line editor using vi. Ian Phillipps.
ctrl.Z How to enter CTRL-sequences in VI. Escape seq. also.
currfn.Z Grab current Filename in VI?
cutpaste.Z Cut and Paste with VI.
demyst.Z Demystifying vi one step further.. A CED discussion.
executing.Z About !shell, piping and unix commands inside VI.
history.Z Various "historical" aspects of VI.
insert.Z About inserting text.
interface.Z Interfaces to vi.
linetolong.Z The infamous 'Line too Long' - What can be done. No answer.
macrolimits.Z Macro limitation
mapping.Z Various about mappings.
mapspace.Z How to map <SPACE>.
maptab.Z How to map <TAB>.
misc.Z Misc stuff.
modeline.Z About modeline and modeline -> Modified
multiple.Z CED: Editing multiple files in VI
nthoccurance.Z Finding the nth occurance of a string
octal.Z How does one deal with characters like \331 ?
paragraph.Z Paragraphs and VI.
parawrap.Z Paragraph wrapping in VI.
readin.Z Reading just a part of a file into current file.
regexp.Z Regular Expression Question (with answer).
repeatcmd.Z Repeating a command.
replace.Z Replacement prompting in vi
sandr.Z CED posting about Search and Replace.
spellcheck.Z The file to read if you wanna use spellchekkers with VI.
startup.Z Starting VI. Cmdline options and .exrc files. CED.
tab2space.Z How to map <TAB> to <SPACE>.
tabs.Z A tip on tabs in VI.
tabing.Z CED: Tabs and VI.
tabs.Z A tip on tabs in VI.
termcap.Z Termcap/VI problem...
toodanger.Z "too dangerous to map that" - No solution yet.
toomuch.Z Too much macro text - Soltuion.
transfer.Z Transferring lines between files in VI
undo.Z A short note about the UNDO mechanism in vi and vile.
vim.Z Some CED postings about the VIM.
vs.emacs.Z Vi vs EMACS and C-editing. Mostly objective opinios. CED
windowrez.Z Vi handling window resizing - No solution yet.
wordwrap.Z Wordwraping and VI.
writeout.Z Writing out a section of a file to another file with vi.
################################################################################
DIRECTORY: pub/vi/programs
This directory has several subdirectories, one for each platfrom
Readme.vim Readme file for the VIM editor.
Readme.xvi Readme file for the XVI editor.
msdos:
calvin21.zip Calvin 2.1 - Formerly "FREE VI".
vim127x.zip Vi IMitator exectuable and docsumentation for MS-DOS.
xvidoc.zip XVI 2.15 documentation for MS-DOS.
xviexe.zip XVI 2.15 executable for MS-DOS.
unix:
bined.tar.Z Filters for edit of binary files. OK for too-long lines.
bvi.tar.Z Binary editor with VI command subset. Excelent ! A must !
reformat.tar.Z A WordStar like reformat. Better than fmt (1) ?
rvi.tar.Z Remote screen editor based on vi
vi-buffer.el.Z Invoke VI inside emacs.
xvi.tar.Z XVI 2.15 source for UNIX (and others).

30
README Normal file
View File

@ -0,0 +1,30 @@
This repo contains the information in the vi archive and FAQ at:
ftp://ftp.uib.no/pub/vi/
as of March 2017.
The archive, lovingly curated by
Ove Ruben R Olsen <ruben@uib.no>
with contributions by many, many people (see WHO), was widely
available via FTP but its availability now is somewhat more limited,
so I place it here for posterity and public availability.
The archive's canonical home was the ftp site at alf.uib.no, with
many mirrors available, but in early 2017 I found it very hard to
locate an ftp site which was a) still up and b) still had a copy
of the archive. In fact, I failed, over the course of an evening's
effort, to locate an extant copy of the archive. Finally, just
before giving up and going to bed, I hit upon the notion of using
ftp.uib.no, instead of alf.uib.no. It worked!
There are enough great ideas and constructs in here to raise anyone's
vi game, and lots of items of historical interest. (There is also a
nifty little perl script called vifs, which allows one to 'push'
documents on to a stack, and 'pop' back to them.)
I never knew that before Vim stood for ViIMproved, it stood for
ViIMitation! (See the README for version 1.27 of vim: Readme.vim in
programs/).

28
WHO Normal file
View File

@ -0,0 +1,28 @@
The folowing persons have contributed to this archive, and I and
the NET owe them a thanks:
Larry V. Wirden (lwv27@CAS.Bitnet) for more than 60 files !
Erik E. Bowles (bowles@is.s.u-tokyo.ac.jp) for a macro and MIRRORING ALF !
Hugh McGuinness (hughm@tplrd.tpl.oz.au) for a macro.
Chet A. Creider (creider@taptet.sscl.uwo.ca) for a vi tutor in LaTeX.
Hans Mulder (hansm@cs.kun.nl) for vi.bined.tar.Z
Geoff Clare (gwc@root.co.uk) for the blocks macros.
Contr Karl Vogel (vogel@c17igpb.wafb.af.mil) for vi.ckv?.Z
Dave Datta (datta@cs.uwp.edu) for MIRRORING ALF !
Bo Thide (bt@irfu.se) for cvi.Z
Mitch Wyle () for vi.crypt.Z
Bill "Rock" Petro (Bill.Petro@Eng.Sun.Com) for exrc.brp.
Alex Martelli (martelli@cadlab.sublink.org) for vi.xvi.tar.Z
Gary Smith (uunet!ddi1!lrark!glsrk!gars) for GEnie MIRRORING.
Roland Bickel (rmbicke@cs.vu.nl) for modula2.new
Steve Balogh (steve@monash.edu.au) for MIRRORING ALF !
Maurizio Codogno (mau@bilbo.CSELT.STET.IT) for vi.chars.tex.Z
Maarten Litmaath (maart@nat.vu.nl) for vi.reference.Z
.
.
.
And others that I unfortunatly have forgot... If you miss your name,
please tell me so...

524
comp.editors.EDS Normal file
View File

@ -0,0 +1,524 @@
newsgroups: comp.editors,news.answers
Approved: news-answers-request@MIT.Edu
Followup-To: poster
Subject: comp.editors - List of editors
Expires: Sun 12 Sep 92 01:28:01 1992 GMT
Reply-To: Ruben@Uib.no
Archive-name: editor-faq/Editor_List
Version: Thu Aug 13 01:27:53 GMT 1992
Intorduction
^^^^^^^^^^^^
This is a list of some of the editors availible on the net.
This list is constantly updated. There will always be a updated
list on the VI/EX archives.
I've restricted the various Emacs implementations to GNU emacs and
microemacs, because of Craig Finseth's posting on emacs implementations.
Also, if I haven't listed an editor here that you want to find, then it
may be a good idea for you to look at the 'How to find sources' article
which is regularly posted to comp.sources.wanted, alt.sources and
news.answers.
And then when you find it, tell me about it. I would be exstremly happy
if you could submit the same information that the editors in this posting
have.
I've tried to list at least ONE site in each part of the world (Europe,
North America, Australia and Asia).
Anonymous FTP
^^^^^^^^^^^^^
To fetch a file from anomymous FTP do the following steps after beeing
connected to the FTP server:
- When the FTP server asks for a login, try either 'anonymous' or
'ftp'.
- When the FTP server asks for a password, your password is the
same as your login-ID and your hostname. To enter this properly,
use the following format:
LoginID@HostName.DomainName.
DO NOT use 'ident' or 'guest' since this is bad nettiquette.
If you are going to use FTP, use the site that is the closest to you
counting NET-VICE. If you don't know what I'm talking about, please
ask someone who know (ie. your system administrator).
Why YOU shold use the site closest to you NET-VICE:
- Faster access.
- Reducing the net load.
- Keeping the site.
Please do NOT use ftp to the sites during peak hours at the various
locations. Please respect this or else, if there is too much FTP'ing
going on prime time to the various places, the ftp site may have to
shut down. NON OF US WOULD WANT THAT, WOULD WE ?
So what is the peak hours at the various places in the world ? - Usualy
from 0800 AM to 0500 PM LOCAL TIME.
Do absolutely NOT post a question to this news-group or other news-groups
questions about how to use FTP. Ask this question to your local system
administrator or at your local help desk. There is also a FAQ on how to
use FTP. Look for it in the news.answers newsgroups.
I need your help !
^^^^^^^^^^^^^^^^^^^
I have only access to UNIX, CMS, VMS and MSDOS computers. Therefore
editors from other machines and OS' will be exstremly limited unless
YOU help me out.
Editor writers
^^^^^^^^^^^^^^
If you are a editor writer I would be happy to receive information about
your editor. What I want is: Editor name, Current release, Maintainer
(name and email adress), what OS the editor run's on. The editor's
file name (Example: fooBarEd.tar.Z) for easy searching with archie is a
must :-), either this or you include FTP sites where the editor is
sure to be found. A description of your editor should be limited to
15 lines of text.
Copyright
^^^^^^^^^
This listing is copyright (C) Ove Ruben R Olsen. All rights reserved.
The listings
^^^^^^^^^^^^
After a Anonymous FTP entry there is a date. This date is when the FAQ
maintainer last cheked the existance of the entry.
The date in the Current release, is the date when the maintainer got
the information about the upgrade or when the upgrade was announced on
NetNews.
001) Ant's Editor.
002) ce
003) Crisp
004) Elvis
005) FPTED
006) GNU Emacs
007) JOE's editor.
008) Jstevie
009) Mutt Editor 2
010) Microemacs
011) Mined
012) Origami
013) pico
014) REDT
015) Sedt Editor
016) SLIM
017) Stevie
018) TECO
019) TERSE
020) Vile
-------------------------------------------------------------------------------
Editor: Ant's Editor.
Current Release: Anthony's Editor May 92
Maintainer: Anthony Howe <ant@mks.com>
Operating system(s):
UXIX based systems.
Atari ST, MS-DOS
AE'92 merges two schools of thought by providing both VI
style (modual) and EMACS style (modeless) editing
interfaces. One can start an editor session in one style
or the other and switch during a session.
The source should be portable to any environment that
provides a K&R C compiler and a CURSES library.
The editor has Online help and support for function keys on
using TERMCAP.
The source can be obtained directly from the author.
--------------
Editor: ce
Current Release: v1.1e (Jun 30 1992)
Maintainer: Charles Henrich (henrich@crs.cl.msu.edu)
Anonymous FTP:
crs.cl.msu.edu:/pub/cedist.tar.Z (920810)
Operating system(s):
UNIX (ATT3B2, SUN, AIX3, NEXT, CONVEX)
The CE editor is a modeless, easy to use and configurable
editor.
The neat thing about this editor is that if your terminal
is not in the set of configured terminals, you can invoke
it with a command line option that prompts you for the
various keystrokes it uses, and then creates a .file for
that terminal for you, so it will always work. It makes
extensive use of function keys, and lets you use escape
sequences if you don't have them.
Submitted by: Steven Fought (keeper@lighthouse.caltech.edu)
--------------
Editor: Crisp
Current Release: 2.2e
Maintainer: Paul Fox <fox@demon.co.uk>
Anonymous FTP:
ftp.uu.net:pub/crisp/cr_2.2e.tar.Z.*
Crisp is a Brief lookalike.
Crisp has also gone comercial for the laiter versions.
--------------
Editor: Elvis
Current Release: 1.5
Maintainer: Steve Kirkendall <kirkenda@jov.cs.pdx.edu>
Anonymous FTP:
prep.ai.mit.edu:pub/gnu/elvis-1.4.tar.Z
ftp.uu.net:packages/gnu/elvis-1.4.tar.Z
Any alt.sources archives for version 1.5.
Operating system(s):
MS-Dos 3.xx and up.
Atari TOS, OS/2, AmigaDOS.
UNIX based systems.
Elvis is one of the best PD Vi clones around. It is not
100% compatible with the real vi/ex. Elvis has many small
extensions, some omissions, and a few features which are
implemented in a slightly different manner. A lot of
people uses Elvis instead of the real 'VI' :-)
--------------
Editor: FPTED
Current Release: R4.0 (18/Feb/92)
Maintainer: Fernando J. G. Pereira (fjp@minerva.inesc.pt)
Anonymous FTP:
minerva.inesc.pt:pub/aplic/fpted4.tar.Z
Operating system(s):
UNIX based systems.
FPTED is a, easy to use, text editor, that allows the user
to do almost all of the most used features in other text
editors. It isn't as powerful as "vi", or "emacs", but I
think, it's easy to use, its runtime version is very small
(in disk space), and it lets you do almost everything you
usually do in other editors.
--------------
Editor: GNU Emacs
Current Release: 18.58
Maintainer: Joseph Arceneux
Anonymous FTP:
prep.ai.mit.edu:pub/gnu/emacs-18.58.tar.Z
ftp.uu.net:packages/gnu/emacs/18.58.Z.*
GNU Emacs is one of the most popular editors around. It's
very big, very powerful and extensible, and lots of people
use it. In a Usenet poll, it had about equal footing with
vi in terms of number of people using it. Gnu.emacs.help
and Comp.emacs are good places to look for more information
about GNU Emacs.
--------------
Editor: JOE's editor.
Current Release: 29 Sept 1988??
Maintainer: Joseph H. Allen <jhallen@wpi.wpi.edu>
Anonymous FTP:
wpi.wpi.edu:stusrc/joe.tar.Z
Joe is a small and easily configurable editor, with
wordstar bindings as default. Apparently the ideal editor
for users coming from the IBM PC/DOS world.
--------------
Editor: Jstevie
Current Release: 1.3
Maintainer: Junn Ohta <ohta@src.ricoh.co.jp>
Anonymous FTP:
utsun.s.u-tokyo.ac.jp [133.11.11.11], as ftp/jstevie1.3.tar.Z
Operating system(s):
UNIX, MS-DOS, OS/2
Jstevie is an improved version of Stevie 3.69 and can be
used to edit Japanese text encoded in either Shift JIS,
7-bit JIS, or EUC, as well as other 8-bit text. It also
features tag stack, abbreviations, and map(!)s. To edit
Japanese on UNIX, you should link it to the ONEW library,
which is a client interface to the Wnn Kanji Server. The
latest version of ONEW is available from etlport.etl.go.jp
[192.31.197.99].
[Sub: Eric E. Bowles <bowles@is.s.u-tokyo.ac.jp>]
--------------
Editor: Mutt Editor 2
Current Release: Unknown
Maintainer: Craig Durland (craig@cv.hp.com)
Anonymous FTP:
hpcvaaz.cv.hp.com:pub/pub/me2.shar.Z
WSMR-SIMTEL20.ARMY.MIL:<msdos.editor>ME_CD22.ZIP (Old MSDOS ver.)
Operating system(s):
HP-UX (Series 800, 700 and 300),
BSD Unix (Sun, Apollo, DEC, etc)
IBM AIX, OSF/POSIX (HP and DEC),
MS-DOS/PC-DOS (IBM PCs and compatibles)
OS/2 and Atari (TOS and MiNT).
ME2 is a medium-small, portable, extendable Emacs' like
editor that is known to compile and run on a wide flavor of
architechtures. Standalone, ME2 is pretty mundane - you
need to customize it to make full use of it. A compiled
language is provided for this as well as lots of example
programs: a C mode, paren matching, a visual towers of
hanoi, incremental searching, programmers calculator, mark
rings, multi file search (and replace) picture mode (from
GNU Emacs), gomoku (from GNU Emacs) and lots more. Other
features include undo and the ability to have concurrent
processes (such as make) running in a buffer (Unix only).
--------------
Editor: Microemacs
Current Release: 3.11
Maintainer: Daniel M. Lawrence <dan@mbds.uucp>
Anonymous FTP:
midas.mgmt.purdue.edu:dist/uemacs311/*
Another easy to use and small editor. Emacs based. Easily
extensible.
--------------
Editor: Mined
Current Release: July 1992 (comp.editors postings)
Maintainer: Thomas Wolff (wolff@inf.fu-berlin.de)
Operating system(s):
UNIX, MS-DOS, VMS
Its original version is the editor that comes along with
Andrew S. Tanenbaum's operating system minix. This version
has som exchangemet over the original: enabling arbitrary
terminals, windows with dynamic size changes, full 8 bit
compatibility and support, function keys, improved user
interface.
Has a great deal of commands. Modeless editor.
This editor is a good candidate for people comming from the
MS-DOS world.
--------------
Editor: Origami
Current Release: 1.6.30
Maintainer: Michael Haardt <u31b3hs@messua.informatik.rwth-aachen.de>
Anonymous FTP:
irisa.irisa.fr:News/comp.binaries.atari.st/volume16/origami
wuarchive.wustl.edu:usenet/comp.binaries.atari.st/volume16/origami
ftp.thp.uni-koeln.de:minix/beta/origami/origami.tar.Z
Origami is a folding editor for Atari ST's, Minix and SunOS.
--------------
Editor: pico
Current Release: 1.4 (Thu Aug 13 00:27:48 GMT 1992)
Maintainer: Found inside the Pine package.
Anonymous FTP:
ftp.cac.washington.edu:/mail/pine/pine.4.3.tar.Z
Pico is originally derived from MicroEmacs 3.6 and is found
inside the 'Pine' mail system composer.
Pico is a simple, modeless, display-oriented text editor based
on the Pine mail system composer. Commands are displayed at
the bottom of the screen, and context sensitive help is provided.
As characters are typed they are immediately inserted into the
text. Editing commands are entered using control-key combinations.
The editor has three basic features: paragraph justification,
case insensitive searching, and a spelling checker.
Michael Seibel (mikes@cac.washington.edu) and Laurence Lundblade
(lgl@cac.washington.edu) has written the Pico editor.
--------------
Editor: REDT
Current Release: Version 2.1 (25 Nov 91 00:12:20 GMT)
Maintainer: Roger Nelson (rnelson@yoda.eecs.wsu.edu)
Operating system(s):
UNIX (SGI/IRIX, HP-UX, SunOS, AT&S/SysV, DEC/ULTRIX)
AmigaOS
REDT follows a VMS/EDT text editing model and is similar to
the SEDT text editor by Anker Berg-Sonne. REDT is curses
based and should compile under any UNIX system.
A version for the Amiga is now available by request.
REDT allows you to make full use of your keyboard so you
can bind commands to almost any escape/control/function key
sequence. A full screen interactive utility is provided to
generate [the human readable] command key binding files.
REDT can be compiled with Mike Sweet's cmenu library for
pulldown menus, and gadgets.
Some of the features:
- Columnwise cut and paste.
- Cursor movement and character insertion past EOLN.
- Format ruler line and paragraph fill and justify.
- Multiple buffers (9).
- Macro language.
The editor can be obtained from the maintainer via email.
He will eventualy setup a anonymous FTP site when SGI
get's on the network in a few months.
--------------
Editor: Sedt Editor
Current Release: Version 4.2 3-Feb-1991
Maintainer: Anker Berg-Sonne (72337,3211%compuserve.com@CS.RELAY.NET)
Anonymous FTP:
aix370.rrz.uni-koeln.de:msdos/editors/sedt40.zip
aix370.rrz.uni-koeln.de:msdos/mswindows/sedtwin.zip
dnpap.et.tudelft.nl:pub/Os2/sedt40.zoo
luga.latrobe.edu.au:pub/os2/editors/sedt40.zoo
wuarchive.wustl.edu:mirrors/msdos/editor/sedt40pc.arc
wuarchive.wustl.edu:mirrors/msdos/editor/sedt40pc.arc
Operating system(s):
IBM-PC MSDOS (and Windows), OS/2
DEC Rainbow, Atari ST
VAX ULTIRX, RISC ULTIRX
SCO SysV, SCO XENIX
EDT editor. Not much information yet.
--------------
Editor: SLIM
Current Release: 0.9 (24 Jul 92 03:40:19 GMT)
Maintainer: Joseph Gil <yogi@cs.ubc.ca>
Anonymous FTP:
cs.ubc.ca:/ftp/pickup/terse/trs140f.zip The full distribution: ~175K
Operating system(s):
MSDOS
The SLIM editor, a bigger brother to TERSE.
SLIM is a big brother of TERSE. It can do anything TERSE
can, and a lot more, including: "read file into buffer"
command, "switch to another file" command <Alt-E>, "go to
line number" command <Alt-G>, "set right margin" command
<Alt-M>, "swap cursor and mark" command <Shift-Tab>, "pump
block thru external filter" command <Alt-F>, "exchange
marked block with paste buffer" command <Keypad *>, "right
margin set" command <Alt-M> and word wrap, and display of
the hexadecimal value of the current char in the status line.
Many features can be easily added to SLIM by virtue of the
"pump block thru buffer command. Word counting, date and
time stamping, formatting, sorting, column summation,
character sets conversions are just a few examples.
Sophisticated users should probably get copy of a DOS port
of the famous UNIX 'sed' and 'awk', and harness their power
to enhance SLIM. The effects of the extenal filter can be
undone.
--------------
Editor: Stevie
Current Release: Unknown
Maintainer: Tony Andrews <onecom!wldrlg!tony>
Anonymous FTP:
ftp.uu.net:usenet/comp.sources.unix/volume15/stevie/*
nic.funet.fi:pub/minix/stevie
Another good vi clone.
--------------
Editor: TECO
Current Release: Unknown
Maintainer: Matt Fichtenbaum
Anonymous FTP:
usc.edu:pub/teco
ftp.uu.net:usenet/comp.sources.unix/volume9/*
munnari.oz.au:comp.sources.unix/volume9/*
The best editor *ever*. :-) Commands look like line noise
(even more so than vi).
The usc.edu has perhaps the most complete collection of
tecos avalible. It has documentation, macros and a wealth
of teco implementations.
--------------
Editor: TERSE
Current Release: 1.4 (24 Jul 92 03:40:19 GMT)
Maintainer: Joseph Gil <yogi@cs.ubc.ca>
Anonymous FTP:
wsmr-simtel20.army.mil:PD1:<MSDOS.EDITOR>TERSE11.ZIP
cs.ubc.ca:/ftp/pickup/terse/trs140f.zip The full distribution: ~175K
cs.ubc.ca:/ftp/pickup/terse/trs140a.zip An abridged distribution: ~27K
Operating system(s):
MSDOS
TERSE is a tiny (only 4096 bytes) but amazingly powerful
full-screen editor for files of up to 64K in length. TERSE
runs on all PC compatible machines. Its command keys are
very similar to those of the famous BRIEF editor (by
UnderWare Inc.). TERSE can edit both UNIX and MS-DOS style
text files as well as binary files. No hacker's disk is
complete without it. No disk, be it hard or floppy, is too
full to include it.
--------------
Editor: Vile
Current Release: 3.9
Maintainer: Paul Fox <pgf@cayman.com>
Anonymous FTP:
ftp.cayman.com:pub/vile/vile3.18shar.Z
Vile is a vi feelalike. It's based around Microemacs, but
modifed to look (feel) like vi. You can't really say its a
vi clone, because its not *that* vi-like.
--------------

261
comp.editors.FAQ Normal file
View File

@ -0,0 +1,261 @@
Newsgroups: comp.editors,news.answers
Approved: news-answers-request@MIT.Edu
Followup-To: comp.editors
Subject: comp.editors - Frequently Asked Questions
Expires: Fri 10 Sep 92 09:07:34 1992 GMT
Reply-To: Ruben@Uib.no
Archive-name: editor-faq/The_FAQ
The following file is a set of Frequently Asked Questions for the group
comp.editors. Certain questions get asked time and again, and this is
an attempt to reduce the bandwidth taken up by these posts and their
associated replies. If you have a question, please check this file
before you post. It may save a lot of peoples time.
This FAQ tends to ignore emacs related questions, as they tend to be
answered adequately in the comp.emacs FAQ.
Please send all comments, discussion, suggestions for new questions and
so on to me, Ove Ruben R Olsen <Ove.R.Olsen@ubb.uib.no>. I'll try to
answer everything I get. I especially need more 'where to get sources'
answers. I'd like some Anonymous UUCP sites, if at all possible.
01) What is comp.editors?
02) Where can I get the latest release of GNU emacs/elvis/crisp/joe/...?
03) Someone has just posted 'my editor is better than your editor'. What
04) Can I get hold of the source code for VI?
05) I have a Emacs question. Should I ask it in comp.editors, or in
06) Someone just mentioned the 'buffer gap method'. What do they mean?
07) How do I reformat paragraphs in vi?
08) Has anyone got a simple editor for Unix?
09) Are there any vi archive sites around?
10) Where can I get vi for VMS?
11) How do I edit binary files with VI ?
12) Why does vi sometimes tell me 'Too much macro text'?
13) Is there a list of bugs in vi?
14) Whats a folding editor?
15) Where can I get the DEC editor EDT for UNIX.
01) What is comp.editors?
Comp.editors is an INET group for the discussion of editors, editing
interfaces and internals generally. For discussion of what an INET
group is, please see the regular postings in news.announce.newusers.
There was discussion some time back about making comp.editors into a
regular usenet group, but so far nothing has come of it.
Almost anything editor-related is acceptable in comp.editors, with a few
caveats (see question 05).
02) Where can I get the latest release of GNU emacs/elvis/crisp/joe/...?
You should check out the companion posting on this issue.
03) Someone has just posted 'my editor is better than your editor'. What
should I do?
Ignore it. Don't post a reply to comp.editors, whatever you do. These
flame wars tend to go on for ages and they never change anyones mind.
If you really must reply use email, or alt.religion.emacs.
04) Can I get hold of the source code for VI?
Not without a AT&T source license. VI is a direct descendent of ed(1),
and is therefore subject to AT&T licensing. Even if you were to get
hold of the code, to remove all of the AT&T code would be impractical.
There are, however a lot of public domain clones of vi around, Elvis and
Stevie being two. You may also want to check out Vile, which is a vi
feelalike, based on Microemacs.
05) I have a Emacs question. Should I ask it in comp.editors, or in
comp.emacs/gnu.emacs.help?
If the question is specifically about an emacs variant, no. You would
probably get more joy from one of comp.emacs or gnus.emacs.help.
Gnu.emacs.help is specifically for GNU Emacs, whereas comp.emacs
encompasses all variants of emacs (Yes, there is more than one type of
Emacs - there are over 50 in fact).
However, If the question is about an emacs in relation to another type
of editor, then its probably ok to post it here.
06) Someone just mentioned the 'buffer gap method'. What do they mean?
An editor can hold text in memory in a number of ways. If you use the
buffer gap, the file is split into two buffers, with the cursor always
between the two buffers, ie:
[ first buffer ][ second buffer ]
^ cursor is here
When the cursor is moved, a character is just copied from one buffer to
the other (depending on direction). This method makes inserting &
deleting and string searching easy. Insertion just requires extending
the first buffer by one character. Deletion is just removing the last
character of the first buffer. For string searching the file can just
be treated as a single string, with care only needing to be taken when
the match straddles the gap. Disadvantages include difficulty with line
based operations, and problems with page faults when the second buffer
is large. It's also quite hard to implement properly on some segmented
architectures. This is the method used by GNU Emacs.
Another method is a linked list of lines. This is exactly what it says.
When you read in the file, you split it up into lines, maintaining
pointers to the previous & next line. Line-based functions are much
easier with this method, but searching isn't so easy.
07) How do I reformat paragraphs in vi?
Rather than write a set of macros to do this for you, it's usually
easier just to use an external program to do it for you. If you have
fmt(1), then {!}fmt will reformat the paragraph under the cursor. This
can be fitted into a macro easily enough.
If you don't have fmt, then you can use nroff(1) similarly (with a few
caveats about getting rid of trailing blank lines).
A format program is also to be found inside the EX/VI archives. The
filename is vi.reformat.tar.Z. It claims to be a WordStar reformat.
08) Has anyone got a simple editor for Unix?
This comes up a lot. The answer is usually Microemacs, or some clone of
it. Another choice might be joe, crisp or fpted. See question 02 for
where to get them from.
09) Are there any vi archive sites around?
Ove Ruben R Olsen maintains one of the biggest vi archive sites around.
His site is mirrored at a number of sites worldwide. See the companion
posting for more information.
10) Where can I get vi for VMS?
Both TPU and GNU Emacs have vi emulations. You can generally find them
in ftp archives.
11) How do I edit binary files with VI ?
To do this you need a program that converts you binary file to
a plain ascii file. In the EX/VI archives there are two programs
to do this:
vi.bed.tar.Z - A good frontend.
vi.bined.tar.Z - Two filters to convert binary files to/from ascii.
Claims to solve the "Line to long" message.
12) Why does vi sometimes tell me 'Too much macro text'?
When vi starts up, it looks in three places for initialisation commands
of some description. It first looks in your EXINIT environmental
variable. If it doesn't find that, then it looks in the current
directory for a file called .exrc (some vi's do this *as well as*
looking at EXINIT anyway), and sources that instead. If it doesn't find
either of these, then it sources $HOME/.exrc.
The problem is that some vi's source both .exrc files anyway (this is
wrong - it should only ever source one), and vi's buffers overflow
giving you the above error message. One more bug found, Mr. Joy.
13) Is there a list of bugs in vi?
Not at the minute. If anyone would like to collect a list of known
bugs, I'd be happy to post it with this FAQ.
14) Whats a folding editor?
Another word for 'folding editor' is 'outline editor'.
This is quite a hard concept to explain without having a folding editor
in front of you to explain with. The idea behind it is to hide text
behind some sort of descriptive heading. For instance, if you were
working on some C code, but didn't want to see the millions of C
headers, you could fold that text away behind the heading 'INCLUDE FILES',
like:
In a normal text editor, the file would look like:
--- begin ---
#include <stdio.h>
#include <stdlib.h>
#include <bar/foo/blrufl.h>
#include <ktb/kick/inside.h>
#include <mary/had/a/little/lamb.h>
int heights()
{
return wuthering();
}
--- end ---
in a folding editor, it might look something like this:
--- begin ---
... INCLUDE FILES
int heights()
{
return wuthering();
}
--- end ---
Of course, the line can be unfolded, and you can see the original text,
and in editors such as Origami, this folding can be nested.
15) Where can I get the DEC editor EDT for UNIX.
[ Information supplied by Castor Fu (castor@drizzle.stanford.edu) ]
1. Using the the GNU Emacs EDT emulator.
This provides you with the key bindings but doesn't really have
the look and feel. One of the nicest things about EDT for novices
is that it really controls a vtxxx terminal competently, and makes
use of highlighting, keypad, etc. to aid casual users. This
implementation is designed for the "expert" edt user who has no
need for such niceties and primarily wants the key bindings for
his keypad.
2. Buy a commercial product. Probably the most widely used such is
EDT+ from:
Boston Business Computing
3 Dundee Park,
Andover, MA 01810
USA
+1 508 470-0444, FAX +1 508 474-8244.
I used their product a little bit on a Multiflow, but not enough to
REALLY tell how good it is.
Their product will probably cost somewhere $500 and $1000. But it
really looks like EDT to me.
3. Wait for DEC to announce it's port of TPU to Ultrix? I heard they
intend to make this a product.
4. We've started using Anker Berg-Sonne's SEDT. It's become the editor
of choice in our group among those who don't already know vi or
emacs, because it's very easy to use. I don't know why, but it is
not widely used/known about in the unix world for some reason.
(See also question 2 for where to find this editor).

78
comp.editors.PNT Normal file
View File

@ -0,0 +1,78 @@
Newsgroups: comp.editors,news.answers,comp.answers
Followup-To: poster
Message-ID: <Ruben9402280919.CSPOINTER.001@alf.uib.no>
From: buboo@alf.uib.no
Expires: Tue, 07 Mar 94 09:19:51 GMT
Subject: Introduction to comp.editors (July 29 1993)
Date: Tue, 28 Feb 94 09:19:50 GMT
Reply-To: buboo@alf.uib.no
Sender: buboo@alf.uib.no
X-FaqTool: FaqWare version 1.00-000 - Copyright(C) Ove Ruben R Olsen
Archive-name: editor-faq/pointer
This message is automatically posted once a week to inform new readers
of what Comp.Editors is about. It also contains where to get the
latest version of the regular postings that is in this group.
If you don't want to see this posting every week, please add the subject
line to your kill file.
The Subject: indicates when this message was last changed.
What is the group comp.editors about ?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Comp.editors is an INET group for the discussion of editors, editing
interfaces and internals generally. For discussion of what an INET
group is, please see the regular postings in news.announce.newusers.
There was discussion some time back about making comp.editors into a
regular usenet group, but so far nothing has come of it.
If, however, you are interested in "EMACS", a very special editor,
then you should look at (and post to) these groups:
comp.emacs
gnus.emacs.help
However, if the question is about an emacs in relation to another type
of editor, then its probably ok to post it here.
There was 4 regular postings to this group:
- List of EMACS implementations (Posted every 2. month).
- The INDEX files in the VI/EX archives around the world (Posted monthly).
- FAQ for Comp.Editors.
The two following FAQ is looking for a new home:
- List of editors.
The files can be found on the following archives:
Europe
alf.uib.no
/pub/vi/comp.editors.ARC Comp.Editors FAQ VI/EX archivelist
/pub/vi/comp.editors.FAQ Comp.Editors FAQ.
Japan
utsun.s.u-tokyo.ac.jp
/misc/vi/comp.editors.ARC Comp.Editors FAQ VI/EX archivelist.
/pub/lpf/misc/comp.editors.FAQ Comp.Editors FAQ.
Mexico, Canada and USA
cs.uwp.edu
/pub/vi/comp.editors.ARC Comp.Editors FAQ VI/EX archivelist.
/pub/lpf/misc/comp.editors.FAQ Comp.Editors FAQ.
pit.mit.edu
/pub/usenet/comp.editors/Emacs_implementations,_list_of,_regular_post_[long]
/pub/usenet/comp.editors/comp.editors_-_VI_Archives
ftp.uu.net
/pub/text-processing/vi/comp.editors.FAQ Comp.Editors FAQ.
/pub/text-processing/vi/comp.editors.ARC Comp.Editors FAQ VI/EX archive.
Australia, NZ and the rest Down Under
monu6.cc.monash.edu.au
/pub/Vi/comp.editors.ARC Comp.Editors FAQ VI/EX archivelist.
/pub/lpf/misc/comp.editors.FAQ Comp.Editors FAQ.
\Ruben.

752
comp.editors/8bit Normal file
View File

@ -0,0 +1,752 @@
From: davis@pacific.mps.ohio-state.edu ("John E. Davis")
Subject: 8 bit clean implies what?
Reply-To: davis@pacific.mps.ohio-state.edu (John E. Davis)
Date: Sat, 6 Feb 1993 18:22:29 GMT
Lines: 46
Hi,
I have a few questions regarding the meaning of 8 bit clean editors.
As I understand it, an editor which is 8 bit clean can display ALL 256
characters on the output device. That is, the character should not be mapped
to a displayable representation (i.e., ascii char 1 to two character sequence
^A). So for example, if character 235 corresponds to the greek letter alpha
on the output device, an alpha should appear when char 235 is sent. In
addition, the editor should be able to take ANY 8 bit character form the input
device and display it. That is, if the input device is capable of sending the
char 235 (alpha), then the char should be deisplayed as above. Is this
correct?
On my PC, the char 255 do not display anything on the screen (just a space).
255 is also -1 when converted to signed char and usually denoted end of file
or something special like that. Is it just a coincidence that 255 displays
nothing on my PC or is this a general feature? Should I make any assumptions
regarding 255? I would like to reserve it for my own purposes.
Finally, are characters with the hi bit set (>= 128) ever involved in keymaps?
This might seem like a silly question but for my purposes, it is the most
important question. I tend to think of keymaps as involving only 7 bit chars,
e.g., escape map. But is any known case of a keymap where the prefix character
has the high bit set?
In case you are wondering, I am working on an editor (JED). Recently, I
released version 0.80 which I thought to be 8 bit clean, but in retrospect, it
is not. I hear people say ``Just treat ALL characters the same!''. However, I
am concerned with memory usage on PCs and I would like to cut corners wherever
I can. Berfore I release the next version (0.81), I want to make SURE that I
get the 8 bit thing correct.
I appreciate any comments on the subject. Thank You.
--
_____________
#___/John E. Davis\_________________________________________________________
#
# internet: davis@amy.tch.harvard.edu
# bitnet: davis@ohstpy
# office: 617-735-6746
#
From: michael@chpc.utexas.edu (Michael Lemke)
Subject: Re: 8 bit clean implies what?
Organization: The University of Texas System - CHPC
Date: Sat, 6 Feb 93 20:38:11 GMT
Lines: 38
In article <DAVIS.93Feb6132229@pacific.mps.ohio-state.edu> davis@pacific.mps.ohio-state.edu (John E. Davis) writes:
>Hi,
>
>I have a few questions regarding the meaning of 8 bit clean editors.
>
>
>As I understand it, an editor which is 8 bit clean can display ALL 256
>characters on the output device.
>That is, the character should not be mapped
>to a displayable representation (i.e., ascii char 1 to two character sequence
>^A).
I don't think this is correct but I am not an expert on this. Check out
what ISO-Latin-1 means. There are quite a lot of control sequences
>128. e.g., CSI which is ESC [? in 7bit. Any terminal sending or
accepting 8bit controls will use them. Secondly, an 8bit clean editor
needs to know what are corresponding uppercase and lower case
characters, e.g. åis lower case of Å.
>Finally, are characters with the hi bit set (>= 128) ever involved in keymaps?
Yes, see my comment above.
>This might seem like a silly question but for my purposes, it is the most
>important question. I tend to think of keymaps as involving only 7 bit chars,
>e.g., escape map. But is any known case of a keymap where the prefix character
>has the high bit set?
I do think but haven't tried that my vt220 will send CSI something or so
if I tell it to use 8bit control chars, which I haven't. You might also
look at the C LC_CTYPE stuff or how that is called, don't have my C book
handy. There is support for 8bit char sets.
Michael
--
Michael Lemke
Astronomy, UT Austin, Texas
(michael@io.as.utexas.edu or UTSPAN::UTADNX::IO::MICHAEL [SPAN])
From: davis@pacific.mps.ohio-state.edu ("John E. Davis")
Subject: Re: 8 bit clean implies what?
Reply-To: davis@pacific.mps.ohio-state.edu (John E. Davis)
Organization: "Dept. of Physics, The Ohio State University"
Date: Sat, 6 Feb 1993 21:16:29 GMT
Lines: 19
In article <1993Feb6.203811.24134@chpc.utexas.edu> michael@chpc.utexas.edu
(Michael Lemke) writes:
...accepting 8bit controls will use them. Secondly, an 8bit clean editor
needs to know what are corresponding uppercase and lower case
characters, e.g. åis lower case of Å.
This is an excellent point that I have not thought of. The natural solution
is through the use of a lookup table. But, in general, this requires TWO
tables: uppercase and lowercase. However, a single CHANGE_CASE table is
sufficient if it is guaranteed that lower_case(x) >= upper_case(x). Does
anyone know if this assumption is valid?
--
_____________
#___/John E. Davis\_________________________________________________________
#
# internet: davis@amy.tch.harvard.edu
# bitnet: davis@ohstpy
# office: 617-735-6746
#
From: michael@chpc.utexas.edu (Michael Lemke)
Subject: Re: 8 bit clean implies what?
Organization: The University of Texas System - CHPC
Date: Sat, 6 Feb 93 22:49:10 GMT
Lines: 31
In article <DAVIS.93Feb6161629@pacific.mps.ohio-state.edu> davis@pacific.mps.ohio-state.edu (John E. Davis) writes:
>In article <1993Feb6.203811.24134@chpc.utexas.edu> michael@chpc.utexas.edu
>(Michael Lemke) writes:
> ...accepting 8bit controls will use them. Secondly, an 8bit clean editor
> needs to know what are corresponding uppercase and lower case
> characters, e.g. å is lower case of Å.
>
>This is an excellent point that I have not thought of. The natural solution
>is through the use of a lookup table. But, in general, this requires TWO
>tables: uppercase and lowercase. However, a single CHANGE_CASE table is
>sufficient if it is guaranteed that lower_case(x) >= upper_case(x). Does
>anyone know if this assumption is valid?
Yes, this is true for at least ISO-Latin-1 and DEC Multinational
Character Set (almost identical). The high order part of these char
sets are pretty much an image of the low order part except the 8th bit
is 1. You should really have a look at the ISO-Latin-1 character
tables, for example in the appendix of a terminal that has 8bit chars
(e.g., vt220 and higher, GraphOn225 and higher). Also think about sort
sequences. An ANSI C implementation must provide functions like
isupper(int C) which are controled by the current locale which in turn
is controled by the setlocale function. I haven't done anything with it
but this is exactly the kind of problem the stuff was invented for.
The world isn't ASCII anymore.
Michael
--
Michael Lemke
Astronomy, UT Austin, Texas
(michael@io.as.utexas.edu or UTSPAN::UTADNX::IO::MICHAEL [SPAN])
From: scott@inferno.Kodak.COM (Kevin Scott)
Subject: Re: 8 bit clean implies what?
Organization: Eastman Kodak Company
Date: Sun, 7 Feb 93 18:30:16 GMT
Lines: 19
For what it's worth, here is my OPINION on what 8-bit clean means:
1) you can use an 8-bit-clean text editor to edit non-text files
(such as .EXE files or .COM files or binary data files). This
would be of occasional use to hack in changes in any embedded text
in the file you are editing. I have been able to use the Turbo C
editor (ver 1.0) to do this type of thing (or perhaps it was a
Turbo Pascal editor; I forget; the timeframe was 1987 or so).
Of course, if you are editing a file that is not intended to be
text, the editor must not have any restriction on line length or
requirement that non-empty files end with a newline (sequence).
2) it is perfectly OK to represent non-printable characters as a
multicharacter sequence (such as ^A for ASCII code 1). What is
"printable" vs. "non-printable" is determined by the environment.
3) it is possible to enter any 8-bit character from the keyboard on
any IBM-PC compatible system. Just hold down Alt while typing the
desired character code on the numeric keypad.
From: jhallen@world.std.com (Joseph H Allen)
Subject: Re: 8 bit clean implies what?
Organization: The World Public Access UNIX, Brookline, MA
Date: Sun, 7 Feb 1993 21:25:10 GMT
Lines: 73
In article <DAVIS.93Feb6132229@pacific.mps.ohio-state.edu> davis@pacific.mps.ohio-state.edu (John E. Davis) writes:
>Hi,
>I have a few questions regarding the meaning of 8 bit clean editors.
>As I understand it, an editor which is 8 bit clean can display ALL 256
>characters on the output device. That is, the character should not be mapped
>to a displayable representation (i.e., ascii char 1 to two character sequence
>^A). So for example, if character 235 corresponds to the greek letter alpha
>on the output device, an alpha should appear when char 235 is sent. In
>addition, the editor should be able to take ANY 8 bit character form the input
>device and display it. That is, if the input device is capable of sending the
>char 235 (alpha), then the char should be deisplayed as above. Is this
>correct?
Yes. But here's another fly in the ointment: You shouldn't be so
eurocentric... there are apparently versions of vt220s which display two
successive characters as a single chinese or japanese character. So you
need to make a mode where all deletes operate on two characters... (I would
appreciate it if someone would elaborate on this more.. I still need to add
this mode to my editor JOE. I don't understand yet if the character set is
broken into half-charatcers which fit together or if the first character is
really a prefix character).
>On my PC, the char 255 do not display anything on the screen (just a space).
>255 is also -1 when converted to signed char and usually denoted end of file
>or something special like that. Is it just a coincidence that 255 displays
>nothing on my PC or is this a general feature? Should I make any assumptions
>regarding 255? I would like to reserve it for my own purposes.
Nope, can't do that. Some international character sets use 255. Originally
I tried to make all of the 'chars' in JOE 'unsigned chars' so that when a
character was returned in an 'int' the range was 0 - 255 instead of -128 -
127. That way -1 could still be an error return. The only problem is that
stupid ANSI compilers give bazillions of warnings (it's bad enough they give
warning for 'char *' being mixed with 'const char *', but char/unsigned-char
warnings are rediculous. I hate ANSI-C. I wish it would go away. (stupid
catering to the IBM PC..)). Anyway, I now use MAXINT (defined as 2^31-1 or
32767) for error returns and have characters in the range of -128 to 127.
You still need to cast them to unsigned sometimes (for table lookup), but
not very often.
I've decided that 'unsigned' as a C keyword is close to useless because of
the compatibility problems, so I now avoid it as much as possible.
>Finally, are characters with the hi bit set (>= 128) ever involved in keymaps?
>This might seem like a silly question but for my purposes, it is the most
>important question. I tend to think of keymaps as involving only 7 bit chars,
>e.g., escape map. But is any known case of a keymap where the prefix character
>has the high bit set?
True gnu-emacs keyboards are supposed to have a Meta- key, which sets the
high bit. In Linux, there is a mode which makes the ALT- key the Meta-
key...
>In case you are wondering, I am working on an editor (JED). Recently, I
>released version 0.80 which I thought to be 8 bit clean, but in retrospect, it
>is not. I hear people say ``Just treat ALL characters the same!''. However, I
>am concerned with memory usage on PCs and I would like to cut corners wherever
>I can.
:-) Software virtual memory...
> Berfore I release the next version (0.81), I want to make SURE that I
>get the 8 bit thing correct.
JED is neat. The extension language looks like reverse-polish LISP, but
without parenthasis.
--
/* jhallen@world.std.com (192.74.137.5) */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
From: michael@chpc.utexas.edu (Michael Lemke)
Subject: Re: 8 bit clean implies what?
Organization: The University of Texas System - CHPC
Date: Sun, 7 Feb 93 21:39:01 GMT
Lines: 36
In article <1993Feb7.183016.23290@kodak.kodak.com> scott@inferno.Kodak.COM (Kevin Scott) writes:
>For what it's worth, here is my OPINION on what 8-bit clean means:
>
>1) you can use an 8-bit-clean text editor to edit non-text files
> (such as .EXE files or .COM files or binary data files). This
> would be of occasional use to hack in changes in any embedded text
> in the file you are editing. I have been able to use the Turbo C
> editor (ver 1.0) to do this type of thing (or perhaps it was a
> Turbo Pascal editor; I forget; the timeframe was 1987 or so).
> Of course, if you are editing a file that is not intended to be
> text, the editor must not have any restriction on line length or
> requirement that non-empty files end with a newline (sequence).
>
>2) it is perfectly OK to represent non-printable characters as a
> multicharacter sequence (such as ^A for ASCII code 1). What is
> "printable" vs. "non-printable" is determined by the environment.
>
>3) it is possible to enter any 8-bit character from the keyboard on
> any IBM-PC compatible system. Just hold down Alt while typing the
> desired character code on the numeric keypad.
This I would call a *binary* editor. A 8-bit clean text editor allows
me to enter any *printable* character from my keyboard, which is done
with the compose key in my current set up. Don't restrict your views
to PCs. As I said in an other post in this thread, it also means the
editor knows how to capitalize åNgSTrÖm as Ångström.
The thing I am using right now does not allow me to do either of these
but I can enter the characters numerically in a similar fashion as you
describe above. Not really 8bit clean but quite a pain.
Michael
--
Michael Lemke
Astronomy, UT Austin, Texas
(michael@io.as.utexas.edu or UTSPAN::UTADNX::IO::MICHAEL [SPAN])
From: upham@cs.ubc.ca (Derek Upham)
Subject: Re: 8 bit clean implies what?
Date: 7 Feb 1993 18:32:33 -0800
Organization: Raven's Auto Body Repair Shop, Mega-Tokyo.
Lines: 24
jhallen@world.std.com (Joseph H Allen) writes:
>Yes. But here's another fly in the ointment: You shouldn't be so
>eurocentric... there are apparently versions of vt220s which display two
>successive characters as a single chinese or japanese character. So you
>need to make a mode where all deletes operate on two characters...
Actually, it gets worse than that. The GB and Big5 character sets
used in Taiwan have FOUR-byte characters. In general, an application
looks at the high-order bit of the byte "n". If it is zero, the byte
is interpreted as 7-bit ASCII. Otherwise it is interpreted as the
first byte of some character in the alternate set. What's more, there
are various ways of interpreting high-bits in successive bytes to
switch between character sets and save space (the specifics now escape
me, unfortunately). In general, if you want to be safe, do everything
on four byte characters internally, and then add conversion interfaces
to work with whatever character set is needed.
Derek
--
Derek Lynn Upham University of British Columbia
upham@cs.ubc.ca Computer Science Department
=============================================================================
"Ha! Your Leaping Tiger Kung Fu is no match for my Frightened Piglet Style!"
From: ketil@edb.tih.no (Ketil Albertsen,TIH)
Subject: Re: 8 bit clean implies what?
Organization: T I H / T I S I P
Date: Mon, 8 Feb 1993 09:07:53 GMT
Lines: 48
In article <DAVIS.93Feb6132229@pacific.mps.ohio-state.edu>, davis@pacific.mps.ohio-state.edu
("John E. Davis") writes:
>As I understand it, an editor which is 8 bit clean can display ALL 256
>characters on the output device.
If you go by international standards (frequently called ANSI standards by the
US community... :->): No. The 190 (+space) characters. There just aren't 256
character (code)s.
The 64 codes from 0 to 31, and 127 (DEL) to 160 are NOT character codes but
control codes. The correct handling is to *process* them rather than to
display them. The processing may have an effect on the display, eg. CR and
LF, both changing the active position, or ESC-sequences switching to a
different character set (among other things), but the codes are not, per se,
"displayed". The "processing" may be limited to simply storing (conserving)
them because the display or software does not support the defined function
for the control code.
Wrt. input: There should be no restriction on how you enter the control
functions. CR (13) has its own key (did you ever notice that uppercase
letters are entered by key combinations?), but there is nothing wrong by
entering ESC [ 1 2 m ("Second alternative font") as a menu choice rather
than as five separate hex values.
But obviously this assumes that you plan to honor ISO character code
definitions. So, many people would say that it is not "clean". But as
another poster commented, there is a distinction between a binary
editor and an 8-bit clean editor. If you want to be able to edit arbitrary
character sets, with arbitrary use of the control codes (CR/LF relocated
to other code positions...), then you need a binary editor. IMHO it is
sufficient for an editor anno 1993 to support ISO character sets -
preferably all of them.
>Is it just a coincidence that 255 displays
>nothing on my PC or is this a general feature? Should I make any assumptions
>regarding 255? I would like to reserve it for my own purposes.
In 8859/1, 255 is umlaut y. In 8859/2, /3 and /4 it is dot above. Several
character sets do not use 160 and 255 because it would prohibit representation
in a 7-bit environment; ISO 2022 distinguishes between 94 and 96 character
C1 sets.
Before you run out to buy the entire collection of ISO standards for character
sets and control functions: If you were to implement all of it, you'd have
enough to do for the rest of your life... Writing a binary editor may be
simpler.
From: wolff@inf.fu-berlin.de (Thomas Wolff)
Subject: Re: 8 bit clean implies what?
Organization: Free University of Berlin, Germany
Date: Mon, 8 Feb 1993 18:15:16 GMT
Lines: 10
scott@inferno.Kodak.COM (Kevin Scott) writes:
>For what it's worth, here is my OPINION on what 8-bit clean means:
>3) it is possible to enter any 8-bit character from the keyboard on
> any IBM-PC compatible system. Just hold down Alt while typing the
> desired character code on the numeric keypad.
Due to some ridiculous mis-function in Microsoft's standard keyboard
driver, one of the codes can not be entered that way. (I seem to remember
it was 156 or so.)
From: guy@Auspex.COM (Guy Harris)
Subject: Re: 8 bit clean implies what?
Date: 8 Feb 93 19:07:55 GMT
Organization: Auspex Systems, Santa Clara
Lines: 15
>>However, a single CHANGE_CASE table is
>>sufficient if it is guaranteed that lower_case(x) >= upper_case(x). Does
>>anyone know if this assumption is valid?
>
>Yes, this is true for at least ISO-Latin-1 and DEC Multinational
>Character Set (almost identical).
I.e., the upper-case version of the German "sz" character has a loweer
code than the lower-case version?
Warning: that is a trick question, at least as I understand the German
case conventions. It may be unwise to assume that translating a string
from lower-case to upper-case can be done simply by replacing each
lower-case letter in the string with a character that's the upper-case
version of that letter.
From: rnelson@wsuaix.csc.wsu.edu (roger nelson;S23487)
Subject: Re: 8 bit clean implies what?
Organization: Washington State University
Date: Mon, 8 Feb 93 20:22:05 GMT
Lines: 34
In article <1993Feb6.224910.3822@chpc.utexas.edu> michael@chpc.utexas.edu (Michael Lemke) writes:
>In article <DAVIS.93Feb6161629@pacific.mps.ohio-state.edu> davis@pacific.mps.ohio-state.edu (John E. Davis) writes:
>>In article <1993Feb6.203811.24134@chpc.utexas.edu> michael@chpc.utexas.edu
>>(Michael Lemke) writes:
>> ...accepting 8bit controls will use them. Secondly, an 8bit clean editor
>> needs to know what are corresponding uppercase and lower case
>> characters, e.g. å is lower case of Å.
>>
>>This is an excellent point that I have not thought of. The natural solution
>>is through the use of a lookup table. But, in general, this requires TWO
>>tables: uppercase and lowercase. However, a single CHANGE_CASE table is
>>sufficient if it is guaranteed that lower_case(x) >= upper_case(x). Does
>>anyone know if this assumption is valid?
>
>
>Yes, this is true for at least ISO-Latin-1 and DEC Multinational
>Character Set (almost identical). The high order part of these char
>sets are pretty much an image of the low order part except the 8th bit
>is 1. You should really have a look at the ISO-Latin-1 character
>tables, for example in the appendix of a terminal that has 8bit chars
>(e.g., vt220 and higher, GraphOn225 and higher). Also think about sort
>sequences. An ANSI C implementation must provide functions like
>isupper(int C) which are controled by the current locale which in turn
>is controled by the setlocale function. I haven't done anything with it
>but this is exactly the kind of problem the stuff was invented for.
>The world isn't ASCII anymore.
>
>Michael
>--
>Michael Lemke
>Astronomy, UT Austin, Texas
>(michael@io.as.utexas.edu or UTSPAN::UTADNX::IO::MICHAEL [SPAN])
From: goer@ellis.uchicago.edu (Richard L. Goerwitz)
Subject: Wide Characters (was Re: 8 bit clean implies what?)
Date: 9 Feb 93 01:43:10 GMT
Organization: University of Chicago
Lines: 18
allen@world.std.com (Joseph H Allen) writes:
>>As I understand it, an editor which is 8 bit clean can display ALL 256
>>characters on the output device.
>Yes. But here's another fly in the ointment: You shouldn't be so
>eurocentric... there are apparently versions of vt220s which display two
>successive characters as a single chinese or japanese character....
The idea is to keep all character-based code potentially indifferent to char-
acter size. Soon we hope that the internationalization/localization issue
will be solved, to some extent, by ISO 10646, which specifies, as I recall,
32-bit wide characters. Somebody correct me if I'm wrong.
--
-Richard L. Goerwitz goer%midway@uchicago.bitnet
goer@midway.uchicago.edu rutgers!oddjob!ellis!goer
From: michael@chpc.utexas.edu (Michael Lemke)
Subject: Re: 8 bit clean implies what?
Organization: The University of Texas System - CHPC
Date: Tue, 9 Feb 93 03:28:15 GMT
Lines: 28
In article <16849@auspex-gw.auspex.com> guy@Auspex.COM (Guy Harris) writes:
>>>However, a single CHANGE_CASE table is
>>>sufficient if it is guaranteed that lower_case(x) >= upper_case(x). Does
>>>anyone know if this assumption is valid?
>>
>>Yes, this is true for at least ISO-Latin-1 and DEC Multinational
>>Character Set (almost identical).
>
>I.e., the upper-case version of the German "sz" character has a loweer
>code than the lower-case version?
Well, not really. But this is indeed tricky as the reverse, lowercasing
SS, is not unique. `MASSE' can be `Masse' or `Maße', depending on context.
As a native German I'd let these cases alone.
>
>Warning: that is a trick question, at least as I understand the German
>case conventions. It may be unwise to assume that translating a string
>from lower-case to upper-case can be done simply by replacing each
>lower-case letter in the string with a character that's the upper-case
>version of that letter.
Michael
--
Michael Lemke
Astronomy, UT Austin, Texas
(michael@io.as.utexas.edu or UTSPAN::UTADNX::IO::MICHAEL [SPAN])
From: rnelson@wsuaix.csc.wsu.edu (roger nelson;S23487)
Subject: Re: 8 bit clean implies what?
Sender: news@serval.net.wsu.edu (USENET News System)
Organization: Washington State University
Date: Tue, 9 Feb 93 07:59:20 GMT
Lines: 34
>>This is an excellent point that I have not thought of. The natural solution
>>is through the use of a lookup table. But, in general, this requires TWO
>>tables: uppercase and lowercase. However, a single CHANGE_CASE table is
>>sufficient if it is guaranteed that lower_case(x) >= upper_case(x). Does
>>anyone know if this assumption is valid?
One will notice that (with the exception of codes 32-63) the lower order
nyble of the ASCII code for the uppercase character is the same as the
respective lowercase character (and also the respective control character).
The most significant bit of the upper order nyble is an encoding of the
shift keys used:
codes 0000 - 0001 Denote a ctrl character Ie Ctrl-A = 0000 0001
codes 0010 - 0011 don't follow the general encoding scheme
^
codes 0100 - 0101 Denote a shifted char. Ie A = 0100 0001
^
codes 1000 - 1111 Denote an unshifted char Ie a = 0110 0001
^
(Note that there are a few exceptions to the shift key encoding:
64,94,95,96,126 and 127.)
>Yes, this is true for at least ISO-Latin-1 and DEC Multinational
>Character Set (almost identical). The high order part of these char
>sets are pretty much an image of the low order part except the 8th bit
>is 1.
Is the shift key encoding of the characters in the 8-bit character set
preserved?
Roger
From: ketil@edb.tih.no (Ketil Albertsen,TIH)
Subject: Re: 8 bit clean implies what?
Sender: ketil@edb.tih.no (Ketil Albertsen,TIH)
Organization: T I H / T I S I P
Date: Tue, 9 Feb 1993 15:37:50 GMT
Lines: 17
In article <1993Feb9.075920.20683@serval.net.wsu.edu>, rnelson@wsuaix.csc.wsu.edu
(roger nelson;S23487) writes:
>One will notice that (with the exception of codes 32-63) the lower order
>nyble of the ASCII code for the uppercase character is the same as the
>respective lowercase character (and also the respective control character).
Basing a case conversion on this is not a good solution. Eg. 8859/2 (suiting
a number of East European languages) follows this pattern with a distance
of 16 for the codes A9 to AF, but a distance of 32 for C0 to DE. True, the
low nibble is the same, but it doesn't help you that much.
IS 6937 also has a distance of 16 for most upper-half codes, but with
exceptions. And there will always be a number of special cases, such as
the German double-s. So, a translation table gets you a lot further. If
you extend the table with some trapping mechanism for special cases, you
could get it good enough for "any" use.
From: ant@mks.com (Anthony Howe)
Subject: Re: 8 bit clean implies what?
Organization: Mortice Kern Systems Inc., Waterloo, Ontario, CANADA
Date: Tue, 9 Feb 1993 14:21:34 GMT
Lines: 52
To my knowledge, 8-bit clean means that you must make no assumptions about
any characters in the character set other than what the ctype macro/functions
tell you. (See ANSI C section 4.3 Character Handling.)
"The header <ctype.h> declares several functions useful for testing
and mapping characters. In all cases the argument is an int, the
value of which shall be representable as an assigned char or shall
equal the value of the macro EOF. If the argument has any other
value, the behaviour is undefined."
int isalnum(int c);
int iscntrl(int c);
int isupper(int c);
...
P.J. Plauger has a column in "The C User Journal". In one issue (which I
can't remember) he discuss <ctype.h> and issues concerning 8-bit clean.
I recommend doing a search back over that last two years for it.
>From my understanding of the quote above, the ctype table must be at least
256 bytes. You must be careful of sign-extension with char pointers, like
{
char *p = "Hi\375\376\377 there";
...
if (isalpha(p[2])) {
...
} else if (iscntrl(p[4])) {
...
}
}
If your compiler defaults to chars being signed, the results of the ctype
ctype table look up will be undefined, since p[2] will be sign-extended to
-3 and p[4] will be sign-extended to -1 and so fall off the bottom of the
table. Also EOF, typically -1, does NOT equal 255. Remember that the
argument is an int, so EOF is really going to be (int) -1 while 255 will
be (unsigned char) 255, which are not the same.
You should come up with a mapping function something like unctrl() that will
represent control characters (non-printables) in a sensible manner. Allow
the mapping to be altered/configured from system to system.
You also have to be careful about 9-bit char. There are still systems
out there that have 9-bit bytes, which would mean a ctype table of 512
bytes. Plauger's article covers all these issues very well.
-ant
--
ant@mks.com Anthony C Howe
Mortice Kern Systems Inc. 35 King St. N., Waterloo, Ontario, Canada, N2J 6W9
"Nice legs. For a human that is." - Worf (Q-pid)
From: jschief@finbol.toppoint.de (Joerg Schlaeger)
Subject: Re: 8 bit clean implies what?
Date: Tue, 09 Feb 93 17:24:01 GMT
Lines: 35
upham@cs.ubc.ca writes in article <1l4go1INNq8v@cascade.cs.ubc.ca>:
> ..................
> switch between character sets and save space (the specifics now escape
> me, unfortunately). In general, if you want to be safe, do everything
> on four byte characters internally, and then add conversion interfaces
> to work with whatever character set is needed.
>
> Derek
>
> --
> Derek Lynn Upham University of British Columbia
> upham@cs.ubc.ca Computer Science Department
> =============================================================================
> "Ha! Your Leaping Tiger Kung Fu is no match for my Frightened Piglet Style!"
>
Hi,
and please don't forget the big- & small endian problem for more than one
byte per character, because you can't besure that your stdin is a keyboard
and that the byteorder is the allways the same.
I've the problem with named pipe's filled with messages from Intel & Motorala
Workstations and 16-Bit charsets.
Is there anyone who knows the solution for every character set,1 & 2 & 4 Byte.
Perhabs a sign like "\n" thats all the same, to detect the need for byteswapping.
Joerg
--
+++++++++++++++++++++++++++++++++++
Joerg Schlaeger
Home: +49 431 682210 (voice & fax & ...)
jschief@finbol.toppoint.de
-----------------------------------
(to be faster with the /2)
+++++++++++++++++++++++++++++++++++
From: jimc@tau-ceti.isc-br.com (Jim Cathey)
Newsgroups: comp.editors
Subject: Re: 8 bit clean implies what?
Date: 10 Feb 93 23:45:35 GMT
Organization: Olivetti North America, Spokane, WA
Lines: 20
In article <729278641snx@finbol.toppoint.de> jschief@finbol.toppoint.de (Joerg Schlaeger) writes:
>and please don't forget the big- & small endian problem for more than one
>byte per character, because you can't besure that your stdin is a keyboard
>and that the byteorder is the allways the same.
Unicode has a magic cookie that's a NOP whose byte-reversed form is also
a (different) NOP. It may be embedded in any string (presumably at the front)
as a byte-sex tag if you need such things.
--
+----------------+
! II CCCCCC ! Jim Cathey
! II SSSSCC ! ISC-Bunker Ramo
! II CC ! TAF-C8; Spokane, WA 99220
! IISSSS CC ! UUCP: uunet!isc-br!jimc (jimc@isc-br.isc-br.com)
! II CCCCCC ! (509) 927-5757
+----------------+
One Design to rule them all; one Design to find them.
One Design to bring them all and in the darkness bind
them. In the land of Mediocrity where the PC's lie.

81
comp.editors/append Normal file
View File

@ -0,0 +1,81 @@
From alm@netcom.com (Andrew Moore)
Subject: Appending to external file with vi?
Date: 8 Jul 92 19:49:43 GMT
Article-I.D.: netcom.#77lg=q.alm
I use the vi (ex?) command format:
:'x,.w file
to write a section of text to an external file (file).
But I don't know good way to append to an existing file.
The best I can think of is:
!'xtee -a file
where ! filters from the current position to 'x through tee.
Any ideas are welcomed. Thank you.
-Andrew Moore <alm@netcom.com>
From hansm@cs.kun.nl (Hans Mulder)
Subject: Re: Appending to external file with vi?
Date: Wed, 8 Jul 1992 23:52:46 GMT
In <#77lg=q.alm@netcom.com> alm@netcom.com (Andrew Moore) writes:
>I use the vi (ex?) command format:
It's an ex command, like everything that starts with ':'.
> :'x,.w file
>to write a section of text to an external file (file).
>But I don't know good way to append to an existing file.
How about:
:'x,.w >>file
Believe it or not, vi just informed me that "Write forms are 'w' and 'w>>'".
I'd swear I've never seen that message before. Typing
:w>
seems to trigger it.
>The best I can think of is:
> !'xtee -a file
>where ! filters from the current position to 'x through tee.
I'd never thought of that. I might have come up with:
:'x,.w !cat>>file
^
where "w !" pipes (a portion of) the buffer into the indicated command.
Note the SPACE between the 'w' and the '!'. Without it, you'd be
creating a file named "cat>>file". (Creating files with shell meta-
characters in their names is always fun. Try creating a file named
"`rm -r $HOME`" sometime. :-)
--
Hans Mulder hansm@cs.kun.nl
From hansm@cs.kun.nl (Hans Mulder)
Subject: Re: Appending to external file with vi?
Date: Fri, 10 Jul 1992 13:51:35 GMT
In <1992Jul10.094141.7431@usage.csd.unsw.OZ.AU> cameron@spectrum.cs.unsw.oz.au (Cameron Simpson) writes:
>pputter@dos-lan.cs.up.ac.za (Mnr Phillip Putter) writes:
>| Use :'x,.w!>>file
>No, just
> :'x,.w>>file
>Note the lack of `!', which changes the meaning completely.
No, they'll both

278
comp.editors/blankline Normal file
View File

@ -0,0 +1,278 @@
From akf@awful.august.com (Andrew Fullford)
Subject: Re: Removing blank lines in vi
Date: Mon, 31 May 1993 04:25:36 GMT
>>>does anyone know how to remove blank lines from a file using vi?.
>Using
> :g/^$/d
>should do the job.
This is splitting hairs, I know, but the original poster said "blank"
lines:
:g/^[ ^I]*$/d
(that's "space tab").
From hansm@wsinti06.info.win.tue.nl (Hans Mulder)
Subject: Re: ddn.n.n.n.n. (oops, one too many) u (was: Removing blank lines in vi)
Date: 1 Jun 1993 21:21:27 +0200
In <1ufv9eINNb1o@uwm.edu> markh@csd4.csd.uwm.edu (Mark) writes:
>Maybe I wasn't totaly clear, in which case I'm sorry. The question is, how
>do you automate this in vi: n.n.n.n.n. (until n fails)?
If you like to live dangerously, type:
:map q n.qm
This makes typing q do what you asked (n.n.n.n.n. until n fails).
And yes, typing u afterwards will ondo the last one.
I usually :w before I do this, and :unmap q when I'm done, just in case.
You might like to know about :set nowrapscan, which stops searches at
both ends of the buffer, which can be useful if you do things like this.
The sole purpose of the m at the end of the :map is to stop vi from
saying "No tail recursion". I don't understand why tail recursion
is not allowed, while general recursion is.
HansM
From dattier@genesis.MCS.COM (DWT)
Subject: Re: Removing blank lines in vi
Date: 27 May 1993 14:14:18 -0500
Reply-To: dattier@genesis.mcs.com (DWT)
dberg@informix.com (David I. Berg) wrote in <dberg.738516173@puma> as others
have written in other articles:
| :g/^$/d
|
| will do the trick.
:v/./d will do it with fewer characters and less shifting.
David W. Tamkin Box 59297 Northtown Station, Illinois 60659-0297
dattier@genesis.mcs.com CompuServe: 73720,1570 MCI Mail: 426-1818
From lau@auriga.rose.brandeis.edu (frankie t. k. lau)
Subject: Re: Removing blank lines in vi < the surest way >
Date: Thu, 27 May 1993 20:14:25 GMT
tgcpwd@rwc.urc.tue.nl (Wim van Dorst/Prof. Penninger) writes:
>In article <1993May27.090951.65821@qut.edu.au> meilak@qut.edu.au writes:
>>does anyone know how to remove blank lines from a file using vi?.
>>locating empty lines can be done with
>> :s/^$/
>>the hard part is removing them!
> :%g/^$/d
From my belived book Unix in a Nutshell by O'Reilly.
:g/^[ ]*$/d
^^
/\
space tab
this way, you can get rid of blank lines with or
without hidden space(s) and tab(s).
-Frankie
From gibson@netcom.com (Bob Gibson)
Subject: Re: multiple blank lines -> one blank line
Date: Thu, 15 Jul 1993 18:53:48 GMT
cat -S filename >newfilename
--
#include <disclaim.std> /* I admit nothing! */
Bob Gibson -- gibson@netcom.com
From dattier@genesis.MCS.COM (David W. Tamkin)
Subject: Re: multiple blank lines -> one blank line
Date: 15 Jul 1993 14:24:29 -0500
Reply-To: dattier@genesis.mcs.com (DWT)
nancym@u.washington.edu (Nancy McGough) wrote in
<223t68$hpf@news.u.washington.edu>:
| I know I've seen this discussed before but I can't
| find the old messages. I'd like to know how to
| convert multiple blank lines to one blank line
| using sed and using vi. Also, is there a unix
| command like grep with a flag that will do this?
If you have Berkeley cat, cat -s will do it. I've read that less -s does
the same thing but I've never seen a version of less where it worked.
NOTE that in SysV cat, the -s option means something else entirely.
sed '/./,/^$/!d' will do it, but if you're using a csh-based shell,
be sure to escape the exclamation point. That has different results
from BSD cat -s if there are blank lines at the top; I'll go into further
detail on that if anyone is interested.
vi cannot do it with native vi or ex commands as far as I know because it
requires examining more than one line of text at a time, but it can with a
shell escape.
David W. Tamkin Box 59297 Northtown Station, Illinois 60659-0297
dattier@genesis.mcs.com CompuServe: 73720,1570 MCI Mail: 426-1818
From hansm@wsinti06.info.win.tue.nl (Hans Mulder)
Subject: Re: multiple blank lines -> one blank line
Date: 16 Jul 1993 19:39:20 +0200
In <224atd$s09@genesis.MCS.COM> dattier@genesis.MCS.COM (David W. Tamkin) writes:
>nancym@u.washington.edu (Nancy McGough) wrote in
><223t68$hpf@news.u.washington.edu>:
>| I know I've seen this discussed before but I can't
>| find the old messages. I'd like to know how to
>| convert multiple blank lines to one blank line
>| using sed and using vi. Also, is there a unix
>| command like grep with a flag that will do this?
>If you have Berkeley cat, cat -s will do it.
>NOTE that in SysV cat, the -s option means something else entirely.
>vi cannot do it with native vi or ex commands as far as I know because it
>requires examining more than one line of text at a time, but it can with a
>shell escape.
There is a native ex mode command to do it:
:g/^$/.,/./-j
, or, if you regard lines with only spaces and tabs as blank:
:g/^[ ]*$/.,/[^ ]/-j
The ^[ is really a ^ and a [, not an escape; between the [] are a
space and a tab.
HansM
From dattier@genesis.MCS.COM (David W. Tamkin)
Subject: Re: multiple blank lines -> one blank line
Date: 16 Jul 1993 13:40:56 -0500
Reply-To: dattier@genesis.mcs.com (DWT)
hansm@wsinti06.info.win.tue.nl (Hans Mulder) wrote in
<226p48$al7@wsinti06.info.win.tue.nl>:
| There is a native ex mode command to do it:
|
| :g/^$/.,/./-j
|
| , or, if you regard lines with only spaces and tabs as blank:
|
| :g/^[ ]*$/.,/[^ ]/-j
|
| The ^[ is really a ^ and a [, not an escape; between the [] are a
| space and a tab.
Thanks for the suggestion, Hans. It works well except at the bottom of the
document. Then, with wrapscan on, the ".,/./" search causes an "Addr 1 >
Addr 2" error; with wrapscan off, it causes a "no match to bottom" error.
Either way, extra blank lines at the foot remain unchanged by the command;
one can remove them by hand.
It's a good alternative in a situation where you cannot (or don't want to)
escape to a shell.
David W. Tamkin Box 59297 Northtown Station, Illinois 60659-0297
dattier@genesis.mcs.com CompuServe: 73720,157From david@cats.ucsc.edu (David Michael Wright)
From: david@cats.ucsc.edu (David Michael Wright)
Newsgroups: comp.editors
Subject: Removing Blank lines
Date: 19 Dec 1993 09:20:18 GMT
Organization: University of California; Santa Cruz
Lines: 23
have a quote from David Tamkin that explains how to remove blank lines:
sed '/./,/^$/!d'
If the lines are not truly empty but contain some spaces or tabs, cat -s
won't help either. This will, though:
sed 's/[ ]*$//
/./,/^$/!d'
where the brackets enclose a space and a tab.
I am not sure, however, to apply this to my file. I tried !}sed ...
and %sed -c and so on, but it did not work. (Am running on System V
unix)
--
"There is nothing in the marginal conditions that
distinguish a mountain from a mole hill"
Kenneth Boulding
All comments are mine---(David Wright)
david@cats.ucsc.edu.
From dattier@genesis.Mcs.Com (David W. Tamkin)
From: dattier@genesis.Mcs.Com (David W. Tamkin)
Newsgroups: comp.editors
Subject: Re: Removing Blank lines
Date: 19 Dec 1993 03:31:41 -0600
Organization: Contributor Account on MCSNet, Chicago, Illinois 60657
Lines: 39
david@cats.ucsc.edu (David Michael Wright) wrote in
<2f16ci$4kv@darkstar.ucsc.edu>:
| have a quote from David Tamkin that explains how to remove blank lines:
| sed '/./,/^$/!d'
Actually, that was to squeeze successive multiple empty lines into one at
a time.
| If the lines are not truly empty but contain some spaces or tabs, cat -s
| won't help either. This will, though:
|
| sed 's/[ ]*$//
| /./,/^$/!d'
|
| where the brackets enclose a space and a tab.
True.
| I am not sure, however, to apply this to my file. I tried !}sed ...
| and %sed -c and so on, but it did not work. (Am running on System V
| unix)
You mean within vi if you don't have BSD cat or GNU cat?
You cannot embed newlines, no matter what, in a shell command at the colon
prompt in vi or ex. But there are at least two ways around it:
First method: put the sed commands into a sedfile; say you've named it
$HOME/sedfiles/squeeze. Then
:%!sed -f $HOME/sedfiles/squeeze
Second method: use sed's -e option to string the commands, like this:
:%!sed -e 's/[ ]*$//' -e '/./,/^$/!d'
David W. Tamkin P. O. Box 3284 Skokie, Illinois 60076-6284
dattier@mcs.com CompuServe: 73720,1570 MCI Mail: 426-1818

63
comp.editors/blockdel Normal file
View File

@ -0,0 +1,63 @@
From jafo@miranda.accum.com (Sean Reifschneider)
Subject: Re: vi - deleting a block of text
Date: Sat, 29 May 1993 00:50:39 GMT
In article <1993May28.033037.18425@trl.oz.au> soh@tmp_ip_003.trl.OZ.AU (Soh Kam Hung) writes:
>mimit@benji.Eng.Sun.COM (Mimi Tam) writes:
>>What is the easiest way in vi to delete a block of text without knowing
>>the line numbers and without knowing how many lines are in the block?
>
>Note: <X> is the name of the mark, a letter in a-z.
That's what I usually do. The other option of course is if you're using elvis,
you can go to the place you want to start the block, type 'v', and it does
reverse marking. You can then move around using the movement keys and type
a command at the end of the block. I prefer ma, d'a myself.
Sean
--
"Love is a lot like war... Easy to start but hard to finish."
Sean Reifschneider, Supreme hack
jafo@accum.com
From mimit@benji.Eng.Sun.COM (Mimi Tam)
Subject: vi - deleting a block of text
Date: 27 May 1993 20:25:59 GMT
Reply-To: mimit@benji.Eng.Sun.COM
What is the easiest way in vi to delete a block of text without knowing
the line numbers and without knowing how many lines are in the block?
Thanks.
-Mimi Tam-
From soh@tmp_ip_003.trl.OZ.AU (Soh Kam Hung)
Subject: Re: vi - deleting a block of text
Date: Fri, 28 May 1993 03:30:37 GMT
mimit@benji.Eng.Sun.COM (Mimi Tam) writes:
>What is the easiest way in vi to delete a block of text without knowing
>the line numbers and without knowing how many lines are in the block?
Note: <X> is the name of the mark, a letter in a-z.
1. Move the cursor to the start of the required block of text. Type
m<X> to store the cursor position in mark <a>.
2. Move the cursor to the end of the block. Type:
d'<X> - delete to the line containing the mark.
or d`<X> - delete to the character at the mark.
Regards,
--
Soh Kam Hung, Network Management Research, | h.soh@trl.oz.au
TRL, POB 249 Clayton, Victoria

62
comp.editors/blocks Normal file
View File

@ -0,0 +1,62 @@
From beaumont@CompSci.Bristol.AC.UK (Tony Beaumont)
Subject: vi macros for block copy/move
Date: 4 Jul 92 13:10:51 GMT
I am using vi and I have four macros defined in my .exrc for block
operations on text:
\C and \c copy a block of text (from between marks a and b) to before
or after the current cursor position.
\M and \m move a block of text (from between marks a and b) to before
or after the current cursor position.
The lines in my .exrc to define these macros are as follows...
map \C mz'b"zy'a'z"zP
map \c mz'b"zy'a'z"zp
map \M mz'b"zd'a'z"zP
map \m mz'b"zd'a'z"zp
My problem is this, whever I do \c or \C I get a beep from my terminal. This
does not happen when I do \M or \m. The beeping seems to come after the text
is put into the z buffer and before moving back to the z mark to put the text.
I do not get the beep if I type the command sequences for \c and \C by hand.
Anyone tell me why I get a beep and how I can get rid of it.
(please reply by email because I don't read this newsgroup often. I'll
post any solutions that work back to the newsgroup)
-Tony Beaumont
========================================================
email: beaumont@uk.ac.bristol.compsci
snail: Tony Beaumont,
Advanced Computing Research Center,
University of Bristol,
Bristol, BS8 1TR,
UK
========================================================
From brandy@tramp.Colorado.EDU (BRANDAUER CARL M)
Subject: Re: vi macros for block copy/move
Date: Tue, 7 Jul 1992 17:27:47 GMT
Using macros to do block copying/moving seems overly complicated since
there are ex/ed commands designed for the purpose. From my SVR3 manual:
(.,.)ma
will move the addressed block after the line addressed by a, while
(.,.)ta
will duplicate the addressed block after the ine addressed by a. Both
work in vi even though ex uses different command names.
Note that with these commands you are no longer restricted to using marks
for selecting the block, although they work just fine.
Cheers - Carl

83
comp.editors/buffer Normal file
View File

@ -0,0 +1,83 @@
From cn@Materna.DE (Carsten Neumann)
Subject: Re: View Content of Buffer
Date: 1 Jul 93 12:57:36 GMT
In <1993Jun30.075639.5512@alf.uib.no> chun@eik.ii.uib.no (Chunming Rong) writes:
> Does anyone know how to view the content of the buffers within VI?
> Emacs has such function.
What's wrong with
"ap
for printing buffer a at cursor location and
u
for clearing this lines?
BTW: Please cut your .sig!
Carsten
--
Carsten Neumann cn@Materna.de (+49 231) 5599-196 (work)
Schwerter Str. 215, DW-4600 Dortmund 41, (+49 231) 448341 (home)
From mac@bnr.ca (Michael Campbell)
Subject: Re: View Content of Buffer [VIM can do this]
Date: 2 Jul 1993 16:56:59 GMT
I have heard a lot of praise for VIM in this group (and others). I
downloaded a copy myself a few weeks ago, to my DOS/Windows box, and
gave it a whirl. I almost immediately removed it from my machine when
I discovered that it *insists* on displaying my .exrc :map commands on
the terminal prior to bringing up the file I have asked it to edit.
The documentation suggests that this is the way it is supposed to act
under DOS. Strangely enough, it doesn't do this under Unix (also
tried the Unix variant of the same version).
So the question is (if you haven't guessed by now!), is there any way
to stop VIM from displaying the :map commands when run under DOS?
This is so annoying that I returned to Elvis, which is very good.
Thanks in advance for any help.
========================================================================
Michael Campbell BNR Inc. Richardson, Tx.
214-684-5595 (ESN 444) Dept 2Q35 email: mac@bnr.ca
========================================================================
"A baby is a bundle of needs that initiates a 20 year parental emergency"
-Gail Sheehy
From darkstar@bach.udel.edu (The Sleepless Wonder)
Subject: Re: View Content of Buffer [VIM can do this]
Date: Fri, 2 Jul 1993 20:31:35 GMT
In article <211pcr$1bb@crchh327.bnr.ca> mac@bnr.ca (Michael Campbell) writes:
>I have heard a lot of praise for VIM in this group (and others). I
>downloaded a copy myself a few weeks ago, to my DOS/Windows box, and
>gave it a whirl. I almost immediately removed it from my machine when
>I discovered that it *insists* on displaying my .exrc :map commands on
>the terminal prior to bringing up the file I have asked it to edit.
>The documentation suggests that this is the way it is supposed to act
>under DOS. Strangely enough, it doesn't do this under Unix (also
>tried the Unix variant of the same version).
>
>So the question is (if you haven't guessed by now!), is there any way
>to stop VIM from displaying the :map commands when run under DOS?
>This is so annoying that I returned to Elvis, which is very good.
>Thanks in advance for any help.
Well, believe it or not, there is a way around it. (I should probably
cross-post this to alt.hackers 8)
Rename _vilerc to something like vile.rc (sounds like a good DOS name).
Then set your exinit environment variable to this: set exinit=so vim.rc
What happens is that vim doesn't find the default rc file so thus
defaults to looking at the env variable for instructions. The
instructions say to source file. When a file is sourced, it doesn't
display the key mappings...
Now, to make two comments. VIM is a great editor/vi clone, with one
exception. VIM has to edit the file in memory. No problem on
systems with flat memory models, but on DOS boxes, you can't edit large
files (approximately anything larger then 700k on my system). I think
that the

80
comp.editors/buffera Normal file
View File

@ -0,0 +1,80 @@
From ray@hebron.connected.com (Ray Berry)
From: ray@hebron.connected.com (Ray Berry)
Newsgroups: comp.editors
Subject: clearing anon vi buffers
Date: 16 Dec 1993 11:01:45 -0800
Organization: Ascendant Systems
Lines: 10
I happily encountered 'elvis' the other day which seems a fairly
high quality effort at a vi clone. I was a bit surprised however
at the fact that it clears the anon buffers when you change files
via :e etc. From a philosophical point of view I can see how this
behavior might be defended. But alas, transporting text between files
with the default cut buffer is a habit I had fallen into.
I'm wondering if there is any formal rule on this point.
I appeal to the vi mavens here for a clarification.
--
ray berry kb7ht rjberry@eskimo.com ray@connected.com 73407.3152@compuserve.com
From creider@taptet.sscl.uwo.ca (Chet Creider)
From: creider@taptet.sscl.uwo.ca (Chet Creider)
Newsgroups: comp.editors
Subject: Re: clearing anon vi buffers
Date: Thu, 16 Dec 1993 21:22:53 GMT
Organization: University of Western Ontario, London
Lines: 15
In article <ray.756068063@connected.com> ray@hebron.connected.com (Ray Berry) writes:
> I happily encountered 'elvis' the other day which seems a fairly
>high quality effort at a vi clone. I was a bit surprised however
>at the fact that it clears the anon buffers when you change files
>via :e etc. From a philosophical point of view I can see how this
>behavior might be defended. But alas, transporting text between files
>with the default cut buffer is a habit I had fallen into.
> I'm wondering if there is any formal rule on this point.
Elvis' behaviour is standard. You should use the letter buffers as
these are not cleared. E.g. "a10yy to put 10 lines into buffer a,
and then (in another file) "ap or "aP.
Chet Creider
<creider@csd.uwo.ca>
From ray@Celestial.COM (Ray Jones)
From: ray@Celestial.COM (Ray Jones)
Newsgroups: comp.editors
Subject: Re: clearing anon vi buffers
Date: Fri, 17 Dec 1993 19:21:37 GMT
Organization: Celestial Software, Mercer Island, WA
Lines: 28
In <ray.756068063@connected.com> ray@hebron.connected.com (Ray Berry) writes:
> I happily encountered 'elvis' the other day which seems a fairly
>high quality effort at a vi clone. I was a bit surprised however
>at the fact that it clears the anon buffers when you change files
>via :e etc. From a philosophical point of view I can see how this
>behavior might be defended. But alas, transporting text between files
>with the default cut buffer is a habit I had fallen into.
> I'm wondering if there is any formal rule on this point.
>I appeal to the vi mavens here for a clarification.
I am not sure what you mean by "anon" buffers in vi. If you are refering to
the "unnamed" buffer, all vi's that I know of clear this buffer between file
when you
:e etc
To transport buffers between files you need to use any of the 26 "named"
buffers [a-z]. To yank text into a named buffer (a in this example)
"a4yy -> yank 4 lines into buffer a
then you can
:e etc
and use
"ap
to put the contents of buffer a into file "etc"
--
INTERNET: ray@Celestial.COM | The probability of one or more
Ray A. Jones; Celestial Software | spelling errors in this missive
8545 S.E. 68th Street | approaches unity. If this bothers you,
Mercer Island, WA 98040;(206) 236-1676 | run it through your spell checker!

1033
comp.editors/ced.tips.1 Normal file
View File

File diff suppressed because it is too large Load Diff

674
comp.editors/ced.tips.2 Normal file
View File

@ -0,0 +1,674 @@
From kirkenda@eecs.cs.pdx.edu (Steve Kirkendall)
Subject: Quoting in ex/vi -- more info
Date: 12 Nov 91 01:15:09 GMT
Organization: Portland State University, Portland, OR
Status: O
The first results are in on my question about character quoting in ex/vi.
The table below shows what I've learned from e-mail, and a few tests.
Please check it out, and let me know of any errors or omissions.
ex vi .exrc characters to quoted
----+----+------+--------------------------------------------------------
\ \ ^V The | command separator
\ ^V n.a. Special control characters on any command line
^V ^V^V ^V Whitespace in a :map or :unmap command
\ \ \ Whitespace in a :set command
\ \ \ Meta-characters in a regexp or substitution text
\ \ \ The %, #, and ! characters in a shell escape/filename
The "ex" column refers to command lines that are interactively typed
into ex, or for ex macros executed via ":@x".
The "vi" column refers to ex command lines that are interactively typed
using vi's ":" command. It also works for vi macros/maps which use ":".
Please note that when you're defining the macro, though, you'll need to
quote any ^Vs to delay their effect until the macro is applied. Also,
to quote a whitespace character in a :map command, you need to actually
insert a ^V into the command line, which is done by hitting ^V twice.
The ".exrc" column refers to commands in the .exrc file, or a file
which is executed via the ":so" command, or for the value of EXINIT.
The quoting character for special control characters is different, but
this is probably due to the serial line discipline, and not so much
ex/vi itself. This also explains why ^V must be typed twice in vi but
only once in ex, to quote whitespace in a :map. Bearing this in mind,
the quoting character is consistent in all contexts except when the
'|' command separator is to be quoted in .exrc files.
-------------------------------------------------------------------------------
Steve Kirkendall kirkenda@cs.pdx.edu Grad student at Portland State U.
From abed@saturn.wustl.edu (Abed M. Hammoud)
Newsgroups: comp.editors
Subject: Vi and Tags file...(please help).
Date: 23 Nov 91 18:36:18 GMT
Organization: Washington University, ESSRL
Status: O
hello, I have been a very..very..dedicated vi user for a long
time now. I was always wondering about what people meant by tag files (I
program in C). I looked up the manuals we have in the lab and I could not
find something that was enough for me to understand what is a tag file
and how to use tags. I do a lot of programming...I have a big library
of functions that I usually call from within my programs...so what can
tags do for me....Please if any body can help me understand this I
would be very thankful.
PS: Please no flames
Thanks a million,
+-------------------------------------------------+-----------------------+
|Abed M. Hammoud (KB0INX) | abed@saturn.wustl.edu |
|Washington University. | Office: |
|Electronic Systems & Signals Research Laboratory.| -Voice:(314) 935-7547 |
|Department of Electrical/Biomedical Engineering. | -FAX: (314) 935-4842 |
|Campus Box 1161, One Brookings Drive. | |
|St. Louis, MO , 63130 USA | |
+-------------------------------------------------+-----------------------+
From kev@sol.acs.unt.edu (Mullet Kevin Wright)
Subject: piping in an ex keymap
Date: 23 Nov 91 19:34:38 GMT
Organization: University of North Texas
Status: O
Recently, I posted a request for a way to do a pipe in an ex keymap.
My post got garbled becuase I left the actual control characters from my
.exrc in and they, and everything east of them, got dropped in my post.
A few intuitive folks knew what I meant anyway and gave me this really
nice solution (that I wasn't able to find in my O'Reilly & Associates
_Learning the vi Editor_ book.
To place a | in an ex shell command, do a ^V^V| to put a literal ^V in front
of it. One ^V will just leave you with a |, you need an actual ^V| in the
text.
Thanks to Steve Kirkendall and Hans Mulder for their insight. I'm writing
this in the inside of my O'Reilly book now. :)
-Kevin Mullet
University of North Texas
From soh@andromeda.trl.OZ.AU (Kam Hung Soh)
Subject: EX / VI delete up-to and including
Summary: Addressing lines in vi and ex
Keywords: vi, ex
Date: 24 Nov 91 02:53:20 GMT
Organization: Telecom Research Labs, Melbourne, Australia
Status: O
I use vi, and I frequently work with logical blocks using ``/'' or
``?'' to find the end or beginning of the block. For example, here is
a LaTeX construct:
\begin{environment}
\begin{environment2}
sfdasfda
sfdafasd
asfdasfdfdas
\end{environment2}
\end{environment}
If I want to delete the inner environment, I usually type:
d/^ \\/ or d?^ \\?
Unfortunately, this leaves the closing symbols behind, i.e:
\begin{environment}
\end{environment2}
\end{environment}
I noticed that the whole inner environment is deleted if I typed:
d/^ \\/+0 or d?^ \\?+0
The ``+0'' after the pattern match makes vi think the line containing
the pattern is included in the text to be deleted. The SunOS 4.0.3
manual on vi make no mention of this. As far as addressing lines is
concerned, what does the trailing ``+0'' mean to vi?
(On a related matter, this operation seems to be equivalent to typing
the following in ex: :.,/^ \\/d and ?^ \\?,.d)
The system I am using: SparcStation 1+, SunOS 4.1.1
Regards,
---
Soh, Kam Hung | h.soh@trl.oz.au | Telecom Research Laboratories,
| +61 3 253 6638 | POB 249 Clayton, Victoria 3168, Australia
From hansm@cs.kun.nl (Hans Mulder)
Subject: Re: EX / VI delete up-to and including
Keywords: vi, ex
Date: 25 Nov 91 14:07:11 GMT
Sender: news@sci.kun.nl (NUnet News Owner)
Organization: University of Nijmegen, The Netherlands
Status: O
In <1991Nov24.025320.16271@trl.oz.au> soh@andromeda.trl.OZ.AU (Kam Hung Soh) writes:
>I use vi, and I frequently work with logical blocks using ``/'' or
>``?'' to find the end or beginning of the block. For example, here is
>a LaTeX construct:
>\begin{environment}
> \begin{environment2}
> sfdasfda
> sfdafasd
> asfdasfdfdas
> \end{environment2}
>\end{environment}
>If I want to delete the inner environment, I usually type:
>d/^ \\/ or d?^ \\?
>Unfortunately, this leaves the closing symbols behind, i.e:
>\begin{environment}
> \end{environment2}
>\end{environment}
>I noticed that the whole inner environment is deleted if I typed:
>d/^ \\/+0 or d?^ \\?+0
>The ``+0'' after the pattern match makes vi think the line containing
>the pattern is included in the text to be deleted. The SunOS 4.0.3
>manual on vi make no mention of this. As far as addressing lines is
>concerned, what does the trailing ``+0'' mean to vi?
Vi distinguishes "line" moves and "character" moves. If you apply the 'd'
operator to a line move, vi deletes the starting line, the target line and
all intervening lines. If you apply the 'd' operator to a character move
that ends on a different line, the parts of the starting and target line not
moved over are not deleted. The '/' operator usually produces character
moves, but the "+0" suffix makes it a line move.
You can replace the "0" by an other line count, e.g. d/foo/+3 deletes line
up to and including the third line following the next occurrence of "foo";
and
d/^\\/-1
does what Kam Hung Soh wants with fewer keystrokes. Actually, he can save
one more keystroke: the '1' is optional, so
d/^\\/-
would also work. FWIW the '+' is also optional.
And you can type several of these offsets, e.g.
d/foo/++
is equivalent to
d/foo/+2
Finally, there is the possibility to tack on another search:
d/foo/;/bar/
deletes up to (but not including) the first occurrence of "bar" after the next
occurrence of "foo".
Oh, and all trailing delimiters are optional.
>(On a related matter, this operation seems to be equivalent to typing
>the following in ex: :.,/^ \\/d and ?^ \\?,.d)
They are exactly equivalent if you :set nowrapscan. Under wrapscan, there
are situations where :.,/foo/d would reply "First address exceeds second",
while d/foo/0 would merrily delete a large part of your buffer.
--
Hope this helps,
Hans Mulder hansm@cs.kun.nl
From mrd@ecs.soton.ac.uk (Mark Dobie)
Subject: Re: Vi and Tags file...(please help).
Date: 25 Nov 91 09:52:58 GMT
Sender: news@ecs.soton.ac.uk
Status: O
In <1991Nov23.183618.21929@wuecl.wustl.edu> abed@saturn.wustl.edu (Abed M. Hammoud) writes:
> hello, I have been a very..very..dedicated vi user for a long
>time now. I was always wondering about what people meant by tag files (I
>program in C). I looked up the manuals we have in the lab and I could not
>find something that was enough for me to understand what is a tag file
>and how to use tags.
I used vi for a few years before I found out about tags. Tags is one
of the features that sets vi apart from a lot of other editors.
> I do a lot of programming...I have a big library
>of functions that I usually call from within my programs...so what can
>tags do for me....Please if any body can help me understand this I
>would be very thankful.
Here is how I use them. You need to run "ctags" to generate a tags file
for vi to use. I usually have a target in my makefile and type "make
ctags" occaisionally to keep it up to date. The ctags command (in the
makefile) looks like,
ctags *.c *.h libsrc/*.c libsrc/*.h
This generates a file called tags with references to all the functions
in the program and library source.
Now in vi, you can place the cursor at the start of a function name and
press ctrl-]. This will take you to the function definition (even in
another directory). You can read it or edit it and then you press
ctrl-^ to return to where you were. That's the simplest way to use
tags.
Any more advanced users out there who might have built a hypertext
system :-)
Mark.
From hansm@cs.kun.nl (Hans Mulder)
Newsgroups: comp.editors
Subject: Re: Vi and Tags file...(please help).
Keywords: tagstack, push, pop
Date: 26 Nov 91 16:29:09 GMT
Organization: University of Nijmegen, The Netherlands
Status: O
In <1991Nov26.135248.6911@cc.ic.ac.uk> cyber@sig.ee.ic.ac.uk (Nick Sales) writes:
>There is also a ":pop" command, which, not unreasonably, pops you up one
>tag, so returning you to your previous pre-push position.
In this version of vi (the one that comes with SunOS 4.1.1, :version says
Version SVR3.1) control-T is bound to :pop.
>There are some (undocumented at my site) options to do with the tagstack
>too: taglength/tl (how long it is), and tagstack/tgstck (?).
Tagstack is a Boolean option, :set notagstack disables the :pop command
(why would anybody want to do that?). There is also a "tags" option,
specifying the list of files to be searched for tag definitions.
>BTW, I also found option "window/wi" in there: anyone know what it does?
It defines the number of lines drawn initially when you jump to a different
part of the buffer. More lines are drawn if you move around locally.
Useful when editing at low baud rates. On some versions of vi you can put
in your .exrc (for example)
:set w300=5 w1200=11
This :sets the window option to 5 when working on 300 baud (or lower),
to 11 when using 1200 baud and the default (screen height-1) when using
a higher line speed.
--
Hope this helps,
Hans Mulder hansm@cs.kun.nl
From gwc@root.co.uk (Geoff Clare)
Newsgroups: comp.unix.misc,comp.editors
Subject: What does this do? (was Re: Vi internal design doc. needed)
Date: 26 Nov 91 14:16:06 GMT
Organization: UniSoft Ltd., London, England
Status: O
In <8460@autodesk.COM> dansmith@Autodesk.COM (Daniel Smith) writes:
> quick! What does this do?
>map ]/ lbywo/^[p"xdd@x
There's no quick answer, because the behaviour depends on the current
cursor position and, if autoindent is set, on whether the current line
is indented and how far.
The following analysis is all done from memory of the behaviour of the
vi commands used, not from trying out the macro, so please accept my
apologies for any inaccuracies. Note that the phrase "beginning of line"
refers to the first non-white-space character on the line.
1. If the cursor is not on the last line of the file and not at the
end of a line, and either the line is not indented or autoindent is
not set, then it searches for the first occurrence of the word under
the cursor plus any white space which follows it, starting the search
from the beginning of the next line.
2. If the cursor is on the last line of the file, then it behaves as in
(1) except that the search starts at the beginning of the current line.
3. If the cursor is at the end of a line, then it beeps and does nothing.
4. If autoindent is set and the current line is indented:
4a. If the indent extends beyond the first tabstop, and tab is not
mapped, then it beeps and moves the cursor to the start of the
next line.
4b. If the indent does not extend beyond the first tabstop, and
the number of spaces of indent does not exceed the number of
characters on the next line (not including any leading white
space), then it behaves as in (1) except that the search begins
N characters from the beginning of the next line, where N is
the number of spaces of indent.
4c. If the indent does not extend beyond the first tabstop, and
the number of spaces of indent exceeds the number of
characters on the next line (not including any leading white
space), then it beeps and moves the cursor to the end of the
next line.
I think that's enough to show that the macro is rather inconsistent in
its behaviour. I can suggest a number of improvements:
If "wb" is used instead of "lb", then it will not fail at the end
of a line, except on the last line of the file.
If "deu" is used instead of "yw", then white space following the
word will not be included in the search.
If "o^[pI/^[" is used instead of "o/^[p", then it will work properly
when autoindent is set and the current line is indented.
If "mx" is added at the start of the macro and "`x" is added before
the "@x", then the search will start from the current cursor
position instead of from the beginning of the next line (or the
current line if it is the last line of the file).
Moral: there's more to writing good vi macros than you might think.
--
Geoff Clare <gwc@root.co.uk> (USA UUCP-only mailers: ...!uunet!root.co.uk!gwc)
UniSoft Limited, London, England. Tel: +44 71 729 3773 Fax: +44 71 729 3273
From jimc@isc-br.ISC-BR.COM (Jim Cathey)
Subject: Re: Vi and Tags file...(please help).
Keywords: tagstack, push, pop
Date: 26 Nov 91 21:58:07 GMT
Organization: ISC-Bunker Ramo, An Olivetti Company
Status: O
>Now in vi, you can place the cursor at the start of a function name and
>press ctrl-]. This will take you to the function definition (even in
>another directory). You can read it or edit it and then you press
GNU Emacs also can use tag files. I believe it can read the files
made by ctags, and it also reads the files made by emacs' etags
program (which I think also will tag lisp files as well as C files).
I believe you follow a tag with M-C-., or something like that (it's
a single keystroke [not counting shifties]). You get back to where
you were with the normal C-X b <ret> command for moving to the
previous buffer. Just fanning the flames...
+----------------+
! II CCCCCC ! Jim Cathey
! II SSSSCC ! ISC-Bunker Ramo
! II CC ! TAF-C8; Spokane, WA 99220
! IISSSS CC ! UUCP: uunet!isc-br!jimc (jimc@isc-br.isc-br.com)
! II CCCCCC ! (509) 927-5757
+----------------+
"PC's --- the junk bonds of the computer industry"
From steveha@microsoft.com (Steve Hastings)
Date: 26 Nov 91 22:08:08 GMT
Reply-To: steveha@microsoft.UUCP (Steve Hastings)
Organization: Microsoft International Products Group
Status: O
In article <1991Nov23.183618.21929@wuecl.wustl.edu> abed@saturn.wustl.edu (Abed M. Hammoud) writes:
> hello, I have been a very..very..dedicated vi user for a long
>time now. I was always wondering about what people meant by tag files (I
>program in C).
Tags are a limited, but nevertheless extremely useful, form of hypertext.
You run a program, usually called "ctags", on your C source code files; it
looks for interesting text, mainly function declarations, and adds what it
finds to your "tags" file.
The "tags" file (which is usually called "tags" -- no big surprise there)
is an index into your sources. Once you have it built, you can type
":ta foo" from vi, and vi will load in the source file where foo() was
defined, and position the cursor on the line where foo() was defined.
There is also a shortcut key, Ctrl+] (to remember this, think "go right
to"). You put the cursor on the first letter of the function you are
interested in, hit Ctrl+], and it jumps to the definition as above.
Depending on the version of vi you have, you may have a "tags stack", where
vi keeps track of where you were before you jumped to the tags reference.
If you have this, Ctrl+T in vi command mode will return you to where you
were before you used Ctrl+] or the :ta command. If you do have the tags
stack feature, you can make multiple jumps with the tags commands, and
still be able to return to where you started; each Ctrl+T takes you
backwards one jump, until you wind up where you started.
Here are two lines from one of my tags files:
AbortLayout layout.c ?^AbortLayout()$?
AddBarChr print3.c ?^AddBarChr( a, b)$?
The first field is the tag to search for, the second field is its filename,
and the last field is a search pattern to use to find the definition line.
Note that vi uses a search command, instead of an absolute line number, so
that the tags file will not be useless after you add or delete lines from
your sources.
If you don't have a tags generator, you can write one using the above
format, or you can manually add tags that weren't automatically generated.
For example, I wrote a program that makes tags from AWK source files.
Other text editors have tags, too. I'm pretty sure EMACS has them.
Words do not adequately describe how handy this feature can be. You want
to know what a function will do with its arguments? Zap -- you are looking
at the function declaration. Done looking? Zap -- you are back where you
were. No time wasted. I never even print out source listings anymore.
--
Steve "I don't speak for Microsoft" Hastings ===^=== :::::
uunet!microsoft!steveha steveha@microsoft.uucp ` \\==|
From mrd@ecs.soton.ac.uk (Mark Dobie)
Subject: Re: Vi and Tags file...(please help).
Keywords: tagstack, push, pop
Date: 27 Nov 91 12:09:22 GMT
Sender: news@ecs.soton.ac.uk
Status: O
In <1991Nov26.162909.23029@sci.kun.nl> hansm@cs.kun.nl (Hans Mulder) writes:
>In <1991Nov26.135248.6911@cc.ic.ac.uk> cyber@sig.ee.ic.ac.uk (Nick Sales) writes:
>>There is also a ":pop" command, which, not unreasonably, pops you up one
>>tag, so returning you to your previous pre-push position.
>In this version of vi (the one that comes with SunOS 4.1.1, :version says
>Version SVR3.1) control-T is bound to :pop.
How could I miss this? Thanks very much. Forget ctrl-^ and use ctrl-T
instead... :-)
Mark.
--
Mark Dobie M.Dobie@uk.ac.soton.ecs (JANET)
University of Southampton M.Dobie@ecs.soton.ac.uk (The World)
From emcmanus@gr.osf.org (Eamonn McManus)
Subject: Fun with tags
Date: 29 Nov 91 16:17:05 GMT
Sender: news@osf.org (USENET News System)
Organization: Open Software Foundation Research Institute, Grenoble
Status: O
I originally posted this message a couple of months back, but have since
discovered that no messages were getting out from OSF at that time.
Since it contains interesting information, I am reposting it.
tchrist@convex.COM (Tom Christiansen) writes:
>From the keyboard of mrd@ecs.soton.ac.uk (Mark Dobie):
>:Tags are one of vi's best features. They could be used for so much
>:more...
>
>We need a 'next-tag' function though. Sometimes there are multiple
>possibilities. This could happen because of having a taglength or
>tagprefix set, but it could also happen in the normal course of events --
>you might have ifdef's around something, etc.
>
>Does anyone have a patch to do this?
In fact with a bit of ingenuity it is possible to do multiple tag
searches without changing vi. One way is to have as many tags
files as there can be entries for a particular tag, and have the
lookup command change to a new tags-file, like this:
<File tags:>
a file1 set tags=tags1|/pattern for a/
b file1 set tags=tags1|/pattern for b/
c file1 /pattern for only occurrence of c/
...
<File tags1:>
a file2 set tags=tags|/pattern for second a/
b file2 set tags=tags2|/pattern for second b/
<File tags2:>
b file3 set tags=tags|/pattern for third b/
Then you map something like this:
" ^\ looks for first definition of following word
map ^\ :set tags=tags^M^]
" ^_ looks for next definition
map ^_ :tag
I imagine the ctags program is among those that have been freed by
Berkeley, so it should be fairly easy to modify it so it can do
this instead of complaining when there are multiple definitions.
It might be better for every tagsX file to have an entry for every
tag than only to have entries in the first N files when there are
N definitions; then you can always use :tag and have it do something
sensible.
Another interesting possibility is to use `command` as the filename
in a tags entry. Thus you would like to have entries like this:
a `lookuptag a` source where
The hypothetical lookuptag program can do arbitrarily complex
processing to determine where a is. It outputs the name of the
file, and puts a pattern or other ex command into the file "where".
There is a small problem with the above scheme, which is that vi
considers the file field in tags to end at the first space or tab;
hence in the above entry it will try to edit "`lookuptag". The
easiest way around this is to define SPACE=' ' in the environment
and use entries like `lookuptag${SPACE}a`. Bourne-ish shell users
can say `lookuptag${IFS}a` instead.
,
Eamonn
From specht.kd@sni-usa.com (Uwe Specht, D10 PU231)
Subject: Re: Vi and Tags file...(please help).
Date: 29 Nov 91 15:42:59 GMT
Sender: specht@usun01.UUCP
Organization: Siemens Nixdorf Informationssysteme AG, Paderborn, Germany
Status: O
you can create your own tags-file with the following syntax:
search_string "filename" ^/search_string .. .. /$
you call this file 'tags' and you can search for it with the
command
vi -t search_string
or when you are in a file you can search with the command
:tags search_string
I hope, that help you a little bit
--
MfG/Regards
Siemens Nixdorf Informationssysteme AG
/ / Specht Abt.: D10 PU2232
/ / ___ Heinz Nixdorf Ring
/ / \ /\ / /__/ W-4790 Paderborn, Germany
\__/ \/ \/ /____ NERV:specht.kd
---------------------------------------------------------------------
Email: specht.kd@sni-usa.com (America (North & South))
specht.kd@sni.de (Rest of world)
From stanj@hpnmdla.sr.hp.com (Stan Jaffe)
Subject: Re: VI search for begin/end of blocks
Date: 4 Nov 91 22:33:30 GMT
Organization: HP Network Measurements Div, Santa Rosa, CA
Status: O
In comp.editors, mrd@ecs.soton.ac.uk (Mark Dobie) writes:
>> I would suggest an approach based on the level of indentation.
Yes, that would be nice. However, the code typically isn't indented.
If it was, I wouldn't need this feature in the first place!
map ^T mx:%s/BEGIN/{@/g^M:%s/END/}@/g^M'x%mz:%s/}@/END/g^M:%s/{@/BEGIN/g^M'z
The macro above maps to cntrl-T, marks the present position, substitutes a
{@ for the BEGIN, a }@ for the END, goes back to the original position,
finds the matching curly-brace, marks that position, then substitutes back
the BEGIN and END, and finally returns to the marked matching position.
This works, but looks like the editor is doing the cha-cha (top to bottom to
etc).
Does anyone have a better way to do this???
Stan Jaffe stanj@sr.hp.com
From dattier@vpnet.chi.il.us (David W. Tamkin)
Subject: Re: how do I macroize c --> |c|
Keywords: vi, macros
Date: 14 Nov 91 22:58:35 GMT
Organization: VPNet Public Access Unix, Villa Park, Illinois 60181-2206
Status: O
rouben@math9.math.umbc.edu (Rouben Rostamian) wrote in
<1991Nov14.120529.13092@umbc3.umbc.edu>:
| In article <ki3ul7INNsfh@agate.berkeley.edu> casterln@are.Berkeley.EDU
| (Gary Casterline) writes:
| >I can't seem to get this to work.
| >:map 'p i|la|
|
| You need to escape the expansion of the | characters by preceeding
| them with ^V.
You need to escape the pipes by preceding each of them with a HARD ^V;
you'll have to type ^V twice before each pipe. Rouben did not make that
clear.
David W. Tamkin Box 7002 Des Plaines, Illinois 60018-7002 +1 708 518 6769
dattier@vpnet.chi.il.us CIS: 73720,1570 MCI Mail: 426-1818 +1 312 693 0580
"Parker Lewis Can't Lose" mailing list:
flamingo-request@esd.sgi.com (reflector) flamingo-request@mcs.com (digest)

697
comp.editors/ced.tips.3 Normal file
View File

@ -0,0 +1,697 @@
From stanj@hpnmdla.sr.hp.com (Stan Jaffe)
Newsgroups: comp.editors
Subject: Using shell filters in VI
Date: 2 Dec 91 19:34:13 GMT
Status: O
This has always puzzled me. Perhaps someone out there knows the answer
to this:
When using the !<line label> feature in vi to write out a selected segment
of a file through a filter, I find that sometimes the text is replaced
"instantaneously" (seemingly all at once), while other times it "scrolls"
through on replacing. (If you don't know what I mean, you probably
haven't experienced it). I don't know if this is something unique to
my hardware/terminal type, or perhaps is related to the speed of my
filter programs. If I could control it, I would much prefer the "all
at once" replacement, since it is easier to see what changed when toggling
using "u". I don't think it has to do with my filter program, because
it has the same behavior when toggling also.
Thanks in advance,
Stan Jaffe stanj@sr.hp.com
From harichan@eecae.ee.msu.edu (Ronald Harichandran)
Subject: VI: Freeing macro space for map command
Keywords: vi map macro
Date: 4 Dec 91 18:42:44 GMT
Status: O
Most implementations of vi have a limit on the amount of mapping that
can be done using the map and map! commands. For HPUX the limit is 512
characters total in combined existing macros. The problem that I have
is that I am unable to free space for new mapping by unmapping some or
all of the existing mappings. In other words, unmapping existing macros
does not seem to free any space. This means that I have to quit vi,
rename the ~/.exrc file in which my usual macros are, then reenter vi to
define new mappings - quite a pain. Any suggestions regarding this
problem are welcome. (This problem also exists on Sun's version of vi.)
Ron Harichandran
Department of Civil & Environmental Engineering
Michigan State University
From adk@sun13.SCRI.FSU.EDU (Tony Kennedy)
Subject: Re: How do do these things in vi?
Date: 7 Dec 91 08:33:18 GMT
In-reply-to: xiaofei@acsu.buffalo.edu's message of 7 Dec 91 03:11:10 GMT
Status: O
xiaofei@acsu.buffalo.edu (XiaoFei Wang) writes:
Subject: How do do these things in vi?
^
And while you're about it could someone kindly tell me:
5) how to change multiple empty lines to one; that is do what the
substitution
:%s/^[ ^I]*$^[ ^I]*$/^$/g
would do if the pattern ^$ really did match and end-of-line
beginning-of-line pair, just as the pattern \n doesn't ;-)
From les@chinet.chi.il.us (Leslie Mikesell)
Subject: Re: How do do these things in vi?
Date: 7 Dec 91 17:59:52 GMT
Status: O
xiaofei@acsu.buffalo.edu (XiaoFei Wang) writes:
>Subject: How do do these things in vi?
>1) change CR to CR/LF [ That is CR plus LF ]
This has to be done before you load into vi (or on the way in) since vi
needs the LF to terminate its concept of a line. Instead of :r file
use :0r !tr '\015' '\012' <file
This gets normal LF endings, so follow by:
>2) change LF to CR/LF [ That is CR plus LF ]
:%s/$/^M/
^type ^V^M for this
>3) delete LF.
> ( msdos to Mac )
Delete the CR first instead:
:%s/^M//
^type^V^M again
Follow by:
>4) change LF to CR.
Do this on the way out:
:w !tr '\012' '015' >file
If you do this a lot, it would probably be worth making shell scripts
for each function using tr and sed. Or, if you are using a file
transfer protocol to move the files among the different machines, just
switch to one like kermit that adjusts the text to the native format
during the transfer.
Les Mikesell
les@chinet.chi.il.us
From xiaofei@acsu.buffalo.edu (XiaoFei Wang)
Subject: Re: How do do these things in vi?
Date: 8 Dec 91 08:49:54 GMT
Status: O
/* From the keyboard of les@chinet.chi.il.us (Leslie Mikesell) */:
*
* >2) change LF to CR/LF [ That is CR plus LF ]
* :%s/$/^M/
* ^type ^V^M for this
*
I found this does not work as expected. Everything gets double spaced
as this. I expected a ^M sign at the end of each line.
--
xiaofei@acsu.buffalo.edu | Subscribe Chinese Poem Exchange and Discussion List
mail LISTSERV@UBVM.BITNET with "SUB CHPOEM-L 1st LastName" in the MESSAGE BODY
Posting address: CHPOEM-L@UBVM.BITNET | InterNet Address: UBVM.CC.BUFFALO.EDU
From dattier@ddsw1.MCS.COM (David W. Tamkin)
Subject: Re: How do you do these things in vi?
Date: 8 Dec 91 05:24:00 GMT
Status: O
adk@sun13.SCRI.FSU.EDU (Tony Kennedy) wrote in
<ADK.91Dec7033318@ds2.sun13.SCRI.FSU.EDU>:
| And while you're about it could someone kindly tell me:
|
| 5) how to change multiple empty lines to one; that is do what the
| substitution
|
| :%s/^[ ^I]*$^[ ^I]*$/^$/g
|
| would do if the pattern ^$ really did match and end-of-line
I think Tony meant "$^".
| beginning-of-line pair, just as the pattern \n doesn't ;-)
vi cannot search for a pattern that crosses line boundaries. If you have
Berkeley cat,
:%!/usr/ucb/cat -s
but in System V cat, the -s flag means something entirely different (to be
_s_ilent about errors) from _s_queeze.
If not,
:%!sed /./,/^$/!d
Neither of those allows for lines that contain nothing but whitespace. You
can do :%s/[ ^I]*$// first to get rid of all trailing whitespace, or you
can change the sed filter to this:
:%!sed /[!-~]/,/^[^!-~]*$/!d
Yes, there two carets there, one on each side of the bracket.
David W. Tamkin Box 7002 Des Plaines, Illinois 60018-7002 +1 708 518 6769
dattier@ddsw1.mcs.com CIS: 73720,1570 MCI Mail: 426-1818 +1 312 693 0580
"Parker Lewis Can't | reflector subscriptions: flamingo-request@esd.sgi.com
Lose" mailing list | digest subscriptions: flamingo-request@ddsw1.mcs.com
From dattier@vpnet.chi.il.us (David W. Tamkin)
Subject: Re: How do do these things in vi?
Date: 7 Dec 91 18:50:15 GMT
Status: O
xiaofei@acsu.buffalo.edu (XiaoFei Wang) wrote in
<1991Dec7.031110.26373@acsu.buffalo.edu>:
| Subject: How do do these things in vi?
|
| 1) change CR to CR/LF [ That is CR plus LF ]
| ( Mac to msdos )
If the file has no LF's in it, vi probably won't be able to handle it. It
will see the entire file as a single line of text. If, however, the entire
file's length is within vi's limit for a single text line, it can read it in
(though it will complain that the last [actually only] line is incomplete).
You can then try this:
:s/\^M/^M/g
where ^M is entered by typing ctrl-V ctrl-M. Note the backslash in the
search string.
If the file is too long for vi to accept it as a single line, change the CR's
to LF's with
tr '\015' '\012' < macfile > unixfile
and go to question #2.
| 2) change LF to CR/LF [ That is CR plus LF ]
| ( Unix to msdos )
If you don't have lef or utod and must do this within vi,
:%s/$/\^M/
where ^M is entered with ctrl-V ctrl-M as in #1. Again, note the backslash.
| 3) delete LF.
| ( msdos to Mac )
That is HIGHLY unadvisable in vi. You can do it by filtering through tr,
but you're FAR better off doing it outside vi because vi needs LF's:
tr -d '\012' < dosfile > macfile
| 4) change LF to CR.
| ( unix to mac ).
As in #3, use tr outside vi:
tr '\012' '\015' < unixfile > macfile
David W. Tamkin Box 7002 Des Plaines, Illinois 60018-7002 +1 708 518 6769
dattier@vpnet.chi.il.us CIS: 73720,1570 MCI Mail: 426-1818 +1 312 693 0580
"Parker Lewis Can't | reflector subscriptions: flamingo-request@esd.sgi.com
Lose" mailing list | digest subscriptions: flamingo-request@ddsw1.mcs.com
From dattier@vpnet.chi.il.us (David W. Tamkin)
Subject: Re: How do do these things in vi?
Date: 8 Dec 91 21:52:23 GMT
Status: O
les@chinet.chi.il.us (Leslie Mikesell) wrote in
<1991Dec7.175952.3773@chinet.chi.il.us>:
| In article <1991Dec7.031110.26373@acsu.buffalo.edu>
| xiaofei@acsu.buffalo.edu (XiaoFei Wang) writes:
...
| >2) change LF to CR/LF [ That is CR plus LF ]
| :%s/$/^M/
| ^type ^V^M for this
That will double-space the entire file. vi, in a :s command's replacement
string, takes ^M to mean a linefeed unless a backslash precedes it. (This is
the sort of thing *Les* usually tells *me*.)
:%s/$/\^M/ is the right syntax.
| >3) delete LF.
| > ( msdos to Mac )
| Delete the CR first instead:
| :%s/^M//
| ^type^V^M again
That will work, even without the backslash (though a backslash wouldn't
hurt). ^M in a target string does match a carriage return [it can't very
well match a linefeed because the target string cannot cross a line boundary].
David W. Tamkin Box 7002 Des Plaines, Illinois 60018-7002 +1 708 518 6769
dattier@vpnet.chi.il.us CIS: 73720,1570 MCI Mail: 426-1818 +1 312 693 0580
"Parker Lewis Can't | reflector subscriptions: flamingo-request@esd.sgi.com
Lose" mailing list | digest subscriptions: flamingo-request@ddsw1.mcs.com
From jerrys@truevision.com (Jerry Schwartz)
Subject: vi window scrolling
Date: 10 Dec 91 21:16:08 GMT
Status: O
How do you get a window to redraw instead of scrolling when doing a
simple search ?
Redraw is faster than an annoying short scroll.
Thanks,
Jerry Schwartz
jerrys@truevision.com
From heinz@marvin.tuwien.ac.at (Heinz Herbeck)
Subject: How to change timeout length in vi without timeoutlen ?
Keywords: vi,timeout,macros
Date: 11 Dec 91 13:16:43 GMT
Status: O
Hello netters,
I just got the macro collection for vi from the alf-archive and copied the
'cvi' macros into my .exrc. Unfortunately my version of vi does not support
the 'timeoutlen' option, it's only possible to toggle 'timeout'. With 'timeout'
set, I have to be *very* fast, because all the macros are three characters
long and the length of the timeout period is less than a second. With
'notimeout', typing text is a pain, because every single letter is a possible
start of a macro. So you never see what you typed until vi decides that you
did not type in a macro (which may take quite long :-(.
I'm running Interactive SVR3.2, :version in vi gives 'Version SVR3.1', hardware
platform is an i486 AT.
Is there a way to change the timeout period even if the appropriate option
does not exist (e.g. patching the executable or other hacks like this) ?
If not, is there a way to get the source code for ex/vi ?
And, no, changing the names of the macros is not the way to go, because there
are *lots* of them and I'd like to keep the names at least a little bit
mnemonic (sp ?). (If everything else fails, well, then I'll have to change
the macro definitions. Sigh.)
All suggestions will be gladly appreciated.
MfG
HH
--
--------------------------------------------------------------------------------
- Heinz M. Herbeck // Technical University of Vienna, Austria -
- EMail: heinz@marvin.tuwien.ac.at // Institute for Computer Graphics -
- herbeck@eichow.una.ac.at // FROM SYSTEM IMPORT StandardDisclaimer; -
--------------------------------------------------------------------------------
From les@chinet.chi.il.us (Leslie Mikesell)
Subject: Re: How do do these things in vi?
Date: 10 Dec 91 17:01:57 GMT
Status: O
In article <1991Dec8.084954.26281@acsu.buffalo.edu> xiaofei@acsu.buffalo.edu (XiaoFei Wang) writes:
>
>* >2) change LF to CR/LF [ That is CR plus LF ]
>* :%s/$/^M/
>* ^type ^V^M for this
>I found this does not work as expected. Everything gets double spaced
>as this. I expected a ^M sign at the end of each line.
Oops - you actually have to type \^V^M to make that one work. And while
I was trying it I also noticed that something very strange happens if you
leave out the ^V. On SysVr3, doing :%s/$/\^M/ adds \377 to the ends
of the lines.
Les Mikesell
les@chinet.chi.il.us
From frank@algol.uucp (Frank Huemme)
Subject: ctrl-u in vi
Date: 12 Dec 91 09:58:11 GMT
Status: O
Hello,
in vi i use Ctrl-d to go down and vi make a jump-scroll. If i use
Ctrl-u to scroll upwards its much slower ( on a terminal or in Xwindows ),
Can i configure vi to use a jump-scrool in that case too ?
Frank
--
Frank Huemme frank@bsa.de email: ..!unido!algol!frank
From chuck@edsi.plexus.com (Chuck Tomasi,Sysop,734-3462)
Subject: Re: vi window scrolling (vt100)
Date: 11 Dec 91 22:32:19 GMT
Status: O
I am using SCO Xenix 2.3.4 on an IBM and I was wondering if someone
could help me with this. The new version of vi uses terminfo, however
my previous version (2.3.2) uses termcap. I was using 2.3.4 vi for a
while, but my users were having too many problems. Rather than try and
modify my terminfo database to match my customized termcap I decided to
go back to the termcap vi from 2.3.2.
Some of the users who were using vt100 emulation noticed that the line
delete worked much better in 2.3.4 in that it would actually delete the
line rather than putting "@" at the beginning and clearing to the end of
the line. I have tried playing with the "dl" entry in termcap for my
vt100 entry, but I just can't seem to make it fly. Does anyone have any
ideas on how to make a vt100 delete the line and what the termcap entry
would look like?
--
Chuck Tomasi | "Seen it." "Hated it" "Taped it."
chuck@edsi.plexus.COM | (Joel) (Servo) (Crow) -- MST3K
-----<Enterprise Data Systems Incorporated, Appleton Wisconsin>-----
From peter@ficc.ferranti.com (peter da silva)
Subject: Re: vi window scrolling
Date: 12 Dec 91 15:37:53 GMT
Status: O
In article <1991Dec10.211608.23849@truevision.com>, jerrys@truevision.com (Jerry Schwartz) writes:
> How do you get a window to redraw instead of scrolling when doing a
> simple search ?
You search far enough ahead that a rewraw is faster than a scroll.
> Redraw is faster than an annoying short scroll.
It may be less annoying for you, but it's not faster. Seriously.
--
-- Peter da Silva
-- Ferranti International Controls Corporation
-- Sugar Land, TX 77487-5012; +1 713 274 5180
-- "Have you hugged your wolf today?"
From peter@ficc.ferranti.com (Peter da Silva)
Subject: Re: vi window scrolling (vt100)
Status: O
OK, a *real* vt100 doesn't have delete and insert line, which is why you're
getting the @ characters: the terminfo entry is for a real circa 1981 vt100.
Select vt220, vt320, or some similar terminal type... or add both insert line
and delete line to the terminfo entry.
--
-- Peter da Silva
-- Ferranti International Controls Corporation
-- Sugar Land, TX 77487-5012; +1 713 274 5180
-- "Have you hugged your wolf today?"
From mdoob@ccu.umanitoba.ca
Subject: Reverse video in vi
Keywords: reverse video, vi
Date: 17 Dec 91 16:23:47 GMT
Vi seems to know most of the termcap entries. Sometimes a message appears
in reverse video on the bottom line of the screen.
Is in possible to get vi to highlight an area in reverse video? Just as
one can yank from the current point to end of line, end of paragraph,
mark a, etc., it would be nice to give a command that would highlight
the screen in the same manner.
Michael Doob
Department of Mathematics
University of Manitoba
From coops@engin.umich.edu (David John Cooper)
Subject: Going crazy with non-vi DOS editor
Date: Tue, 17 Dec 91 22:21:20 EST
Status: O
I have found myself in a DOS development situation,
and am going crazy trying to use the "user-friendly"
non-vi editors (qedit, dos edit, brief, etc...)
Does anyone know of a shareware vi for DOS, or where
there is "gnu" sourcecode or the like for a vi editor?
dave
coops@engin.umich.edu
P.S. I have a (I think shareware) DOS vi called "z"
by Jom Goodnow, but it only handles files of up to
about 50k and doesn't have global search and replace,
file toggle (with e#) and is missing many other goodies)
(also only handles 7-bit characters).
From kev@sol.acs.unt.edu (Mullet Kevin Wright)
Subject: ex command to delete blank lines
Date: 23 Dec 91 14:37:32 GMT
Status: O
...okay, I'll take a vi command too, but I assume if I want to do
this in vi it'll be done at the ex level.
This sounds real easy, but I can't figgure a way to do it -- I want to
kill all blank lines in a vi buffer.
I know there's probably lotsa ways to do this with vi !!filters through
a script, but I'm interested in seeing if there's a way to do this from
vi or ex alone.
Please send to me and I'll post to the net.
-Kevin Mullet
University of North Texas
From xiaofei@acsu.buffalo.edu (XiaoFei Wang)
Subject: Re: ex command to delete blank lines
Date: 26 Dec 91 12:11:04 GMT
Status: O
/* From the keyboard of kev@sol.acs.unt.edu (Mullet Kevin Wright) */:
:...okay, I'll take a vi command too, but I assume if I want to do
:this in vi it'll be done at the ex level.
:This sounds real easy, but I can't figgure a way to do it -- I want to
:kill all blank lines in a vi buffer.
:I know there's probably lotsa ways to do this with vi !!filters through
:a script, but I'm interested in seeing if there's a way to do this from
:vi or ex alone.
I am not sure why no one posts an answer. I am no unix/vi expert but I
will post one:
:1,$!sed -e '/^ *$/d'
--
xiaofei@acsu.buffalo.edu | Subscribe Chinese Poem Exchange and Discussion List
mail LISTSERV@UBVM.BITNET with "SUB CHPOEM-L 1st LastName" in the MESSAGE BODY
InterNet Address: UBVM.CC.BUFFALO.EDU | Posting in UUENCODED GB and BIG5
From lutwak@athena.mit.edu (Robert Lutwak)
Subject: Re: ex command to delete blank lines
Date: 26 Dec 91 14:14:45 GMT
Status: O
How about:
:1,$ g/^$/d
From dylan@ibmpcug.co.uk (Matthew Farwell)
Subject: Re: ex command to delete blank lines
Date: 28 Dec 91 23:40:58 GMT
Status: O
In article <1991Dec26.121104.3477@acsu.buffalo.edu> xiaofei@acsu.buffalo.edu (XiaoFei Wang) writes:
>/* From the keyboard of kev@sol.acs.unt.edu (Mullet Kevin Wright) */:
>:...okay, I'll take a vi command too, but I assume if I want to do
>:this in vi it'll be done at the ex level.
>
>:This sounds real easy, but I can't figgure a way to do it -- I want to
>:kill all blank lines in a vi buffer.
>
>:I know there's probably lotsa ways to do this with vi !!filters through
>:a script, but I'm interested in seeing if there's a way to do this from
>:vi or ex alone.
>
>I am not sure why no one posts an answer. I am no unix/vi expert but I
>will post one:
>
>:1,$!sed -e '/^ *$/d'
I didn't see this first time round. Theres no need to resort to sed this
time (although your example will work). You can do this using the 'g'
command, ie
:g/^$/d
g stands for 'global'. The effect of the command is to execute the
specified ex command (in this case 'd') on every line which matches the
pattern. 'g' has a converse, 'v', which means execute the command on
every line *not* matching. The generic format for the g and v command is
:<range>g/<pat>/<ex command>
Most vi's accept the range, although I'm not sure if all do. If your vi
does let you use it, it's of the usual form, ie '1,$', etc. the /'s can
be replaced by another punctuation character, as normal. The ex command
can be almost anything.
Quick example: You want to replace all occurences of 'foo' with 'bar' on
each line which contains the string 'walter', and each previous line.
The search is restricted to the first 1000 lines.
:1,1000g/walter/.-1,.s/foo/bar/g
Everyone got that? I'll be asking questions on it later....
Dylan.
--
dylan@ibmpcug.co.uk || ...!uunet!uknet!ibmpcug!dylan
It is sometimes hard to decide whether Usenet is a glimpse into the 21st
century or a New England town meeting gone international - Andrew Tanenbaum
From ado@elsie.nci.nih.gov (Arthur David Olson)
Subject: Re: ex command to delete blank lines
Status: O
> > :1,$!sed -e '/^ *$/d'
>
> :g/^$/d
Or use
:v/./d
and save a keystroke and two shifts.
--
Arthur David Olson ado@elsie.nci.nih.gov
ADO and Elsie are Ampex and Borden trademarks
From wagner@hatteras.cs.unc.edu (Michael Wagner)
Subject: vi (including file name)
Date: 9 Jan 92 20:47:44 GMT
Status: O
I'm working on a macro (in vi) that would allow me
to automatically write the name of the file into
the current cursor location in the file.
I know that "%" seems to be the name of the file,
it seems that you can rename a file with
:w %.new
I think I could usually simulate what I want with a
:r !ls %
but there has to be a better way.
Mike
From steinbac@hpl-opus.hpl.hp.com (Guenter Steinbach)
Subject: Re: vi (including file name)
Date: 10 Jan 92 23:41:01 GMT
Status: O
In comp.editors, wagner@hatteras.cs.unc.edu (Michael Wagner) writes:
> I'm working on a macro (in vi) that would allow me
> to automatically write the name of the file into
> the current cursor location in the file.
Yes! I'd like that also. Right now all I can do is ^G to display the
name, then cut it with the mouse (under X11) and paste it where I need
it. But a macro would be so much nicer.
> I think I could usually simulate what I want with a
> :r !ls %
Usually, but not before the file has been written, else instead of
"filename" you'll get "filename not found".
Guenter Steinbach steinbac@hpl-opus.hpl.hp.com
From dattier@gagme.chi.il.us (David W. Tamkin)
Subject: Re: vi (including file name)
Date: 10 Jan 92 23:30:03 GMT
Status: O
wagner@hatteras.cs.unc.edu (Michael Wagner) wrote in <8656@borg.cs.unc.edu>:
| I'm working on a macro (in vi) that would allow me
| to automatically write the name of the file into
| the current cursor location in the file.
:r !echo % will write it below the current line, and
:-r !echo % will write it above the current line.
David W. Tamkin Box 7002 Des Plaines, Illinois 60018-7002 +1 708 518 6769
dattier@gagme.chi.il.us CIS: 73720,1570 MCI Mail: 426-1818 +1 312 693 0580
From ttobler@unislc.uucp (Trent Tobler)
Subject: Re: vi (including file name)
Date: 13 Jan 92 17:40:53 GMT
Status: RO
steinbac@hpl-opus.hpl.hp.com (Guenter Steinbach) writes:
> In comp.editors, wagner@hatteras.cs.unc.edu (Michael Wagner) writes:
>
>
> > I'm working on a macro (in vi) that would allow me
> > to automatically write the name of the file into
> > the current cursor location in the file.
>
> Yes! I'd like that also. Right now all I can do is ^G to display the
> name, then cut it with the mouse (under X11) and paste it where I need
> it. But a macro would be so much nicer.
>
> > I think I could usually simulate what I want with a
> > :r !ls %
> Usually, but not before the file has been written, else instead of
> "filename" you'll get "filename not found".
would
:r !echo %
work?
--
Trent Tobler - ttobler@csulx.weber.edu

441
comp.editors/ced.tips.4 Normal file
View File

@ -0,0 +1,441 @@
From wagner@hatteras.cs.unc.edu (Michael Wagner)
Subject: vi (including file name)
Date: 9 Jan 92 20:47:44 GMT
Status: RO
I'm working on a macro (in vi) that would allow me
to automatically write the name of the file into
the current cursor location in the file.
I know that "%" seems to be the name of the file,
it seems that you can rename a file with
:w %.new
I think I could usually simulate what I want with a
:r !ls %
but there has to be a better way.
Mike
From steinbac@hpl-opus.hpl.hp.com (Guenter Steinbach)
Subject: Re: vi (including file name)
Date: 10 Jan 92 23:41:01 GMT
Status: O
In comp.editors, wagner@hatteras.cs.unc.edu (Michael Wagner) writes:
> I'm working on a macro (in vi) that would allow me
> to automatically write the name of the file into
> the current cursor location in the file.
Yes! I'd like that also. Right now all I can do is ^G to display the
name, then cut it with the mouse (under X11) and paste it where I need
it. But a macro would be so much nicer.
> I think I could usually simulate what I want with a
> :r !ls %
Usually, but not before the file has been written, else instead of
"filename" you'll get "filename not found".
Guenter Steinbach steinbac@hpl-opus.hpl.hp.com
From dattier@gagme.chi.il.us (David W. Tamkin)
Subject: Re: vi (including file name)
Date: 10 Jan 92 23:30:03 GMT
Status: O
wagner@hatteras.cs.unc.edu (Michael Wagner) wrote in <8656@borg.cs.unc.edu>:
| I'm working on a macro (in vi) that would allow me
| to automatically write the name of the file into
| the current cursor location in the file.
:r !echo % will write it below the current line, and
:-r !echo % will write it above the current line.
David W. Tamkin Box 7002 Des Plaines, Illinois 60018-7002 +1 708 518 6769
dattier@gagme.chi.il.us CIS: 73720,1570 MCI Mail: 426-1818 +1 312 693 0580
From ttobler@unislc.uucp (Trent Tobler)
Subject: Re: vi (including file name)
Date: 13 Jan 92 17:40:53 GMT
Status: O
steinbac@hpl-opus.hpl.hp.com (Guenter Steinbach) writes:
> In comp.editors, wagner@hatteras.cs.unc.edu (Michael Wagner) writes:
>
>
> > I'm working on a macro (in vi) that would allow me
> > to automatically write the name of the file into
> > the current cursor location in the file.
>
> Yes! I'd like that also. Right now all I can do is ^G to display the
> name, then cut it with the mouse (under X11) and paste it where I need
> it. But a macro would be so much nicer.
>
> > I think I could usually simulate what I want with a
> > :r !ls %
> Usually, but not before the file has been written, else instead of
> "filename" you'll get "filename not found".
would
:r !echo %
work?
--
Trent Tobler - ttobler@csulx.weber.edu
From gerolima@netlabs.com (Mark Gerolimatos)
Subject: VI: Changing case for an entire word...how did I do it?
Date: 19 Jan 92 01:58:39 GMT
Status: O
Somehow, I managed to do this by accident. Just now, I did it again.
And the damned thing is that I don't know how!
Now, '~' will toggle the case of a character, but it seems to be immune to the
standard VI [count] command [address modifier] syntax (i.e. '~w' will toggle
the case of the current character, and then move on to the next word).
How did I do this?
If possible, please respond via mail...
-Mark
P.S. If it's in the manual, I couldn't find it...
====================================Cut Here====================================
gerolima@neon.stanford.edu "Righteousness comes ONLY from Jesus Christ...
@netlabs.com ...NEVER from an apron."
-Jack T. Chick
================================================================================
From gregg@cbnewsc.cb.att.com (gregg.g.wonderly)
Subject: Re: How do I... (vi or awk question, perhaps?)
Date: 25 Jan 92 00:02:07 GMT
Status: O
>From article <1992Jan16.215423.11078@ux1.cso.uiuc.edu>, by weller@osiris (Bonnie Weller):
> For instance, my vi file looks like this...
>
> Field 1 Field 2
> Record# Coorx Coory
>
> 1 1234 4321
> 2 1111 4444
> 3 2222 3333
>
>
> I want it to look like this....
>
> Field 1 Field 2 Field 3
> Record# Coorx Coory Label
>
> 1 1234 4321 1
> 2 1111 4444 2
> 3 2222 3333 3
Two people have suggested using awk, and their solutions involve doing
something with an intermediate file. From within vi, you can filter
your file by doing the following. On the top line of your
file, add the following line.
!Gawk '{printf "\%s\%8d\n", $0, NR}'
Next type
1G"ayy
to put the top line (the one with awk on it) into the buffer a.
Next, put the cursor at the beginning of the first line of data
that you want to change. Then, type
@a
to tell vi to eat the contents of buffer a as keystrokes you have typed.
If you don't like the spacing, type a 'u' to undo the changes, and change
the '%8' to be '%5', or something. Then start over at "Next type"
above.
Filtering and using the named buffers as macros are very useful parts
of vi. Knowing how to use them can save you many hours of work...
--
-----
gregg.g.wonderly@att.com (AT&T bell laboratories)
From lwv26@cas.org (Larry W. Virden)
Subject: Re: .exrc location(s)
Date: 25 Jan 92 15:53:13 GMT
Status: O
In article <1992Jan24.211333.18456@jpradley.jpr.com> jpr@jpradley.jpr.com (Jean-Pierre Radley) writes:
:In article <1992Jan24.001030.8749@samba.oit.unc.edu> uevans@med.unc.edu (Elizabeth A. Evans) writes:
:>So why am I finding that the file has to be in (or linked to) every
:>subdirectory I'm in during a vi session? Is there some other way
:>I should do it?
:
:Try putting it into your $HOME directory; vi looks there too.
:
:I don't use a .exrc file, since it's alledgedly quicker to put the information
:into an EXINIT environment variable, which I do in my .profile or .login.
:
:You can "localize" your vi macros, if the last thing in your $HOME/.exrc, or in
:your EXINIT, is ":so .exrc+". Then you can have a different .exrc+ in your
:directory for for new C code; in your directory for mail, etc. Most often, the
:kind of macros I'd put in a .exrc+ would concern sw and wm.
1. I dont know why some folks on Suns seem not get to their ~/.exrc used,
unless they have EXINIT set to "" - it should be unset altogether!
2. A warning about many vi's that I have used. It appears that the .exrc
handling isnt too smart. For instance, if you edit a file in your HOME
directory - .exrc gets read twice (once as your HOME exrc and once for your
local perhaps?). Well, so what? If you have a lot of macros defined in
your HOME/.exrc, you will find you start getting error msgs when you edit
in your HOME directory - you run the macro code out of buffer space. The
thing is, if you have the same macro defined IDENTICALLY (or any other way)
both definitions appear in vi's macro buffer - I believe he only executes
the last one - but the others are still there.
Sigh.
--
Larry W. Virden UUCP: osu-cis!chemabs!lwv26
Same Mbox: BITNET: lwv26@cas INET: lwv26@cas.org
Personal: 674 Falls Place, Reynoldsburg,OH 43068-1614
America Online: lvirden
From jpr@jpradley.jpr.com (Jean-Pierre Radley)
Subject: Re: vi macro def at startup
Date: 26 Jan 92 18:57:42 GMT
Status: O
In article <sjreeves.920125112507@eng.auburn.edu> sjreeves@eng.auburn.edu (Stan Reeves) writes:
>I want to define a macro in my ~/.exrc file, but it doesn't seem to work.
>For example, I put
>
>:map t dd
>
>in the ~/.exrc file to test it, and it doesn't take. I don't have another
>.exrc file in the directory I was using. Any ideas?
One little colon!
If you're already inside 'vi', then typing
:map t dd
would map 't' to 'dd'.
But that ':' doesn't belong in your .exrc file.
--
Jean-Pierre Radley Unix in NYC jpr@jpr.com jpradley!jpr CIS: 72160,1341
From mike@swsrv1.cirr.com (Mike Haddon)
Subject: Re: vi macro def at startup
Date: 26 Jan 92 21:44:11 GMT
Status: O
In article <sjreeves.920125112507@eng.auburn.edu> sjreeves@eng.auburn.edu (Stan Reeves) writes:
>I want to define a macro in my ~/.exrc file, but it doesn't seem to work.
>For example, I put
>
>:map t dd
I am doing this in my .exrc file as:
map P :t dd
where P is the macro identifier to use when you want to execute the macro
and it works pretty well.
--
******************************************************************************
* | | *
* Mike Haddon | 6717 Woodsmoke Way | Fort Worth, Tx. 76137 *
* mike@swsrv1.cirr.com | ...!egsner!swsrv1!mike | ...!void!swsrv1!mike *
From hansm@cs.kun.nl (Hans Mulder)
Subject: Re: vi macro def at startup
Date: 29 Jan 92 02:20:08 GMT
Status: O
In <1992Jan26.185742.11545@jpradley.jpr.com> jpr@jpradley.jpr.com (Jean-Pierre Radley) writes:
>In article <sjreeves.920125112507@eng.auburn.edu> sjreeves@eng.auburn.edu (Stan Reeves) writes:
>>:map t dd
>One little colon!
>But that ':' doesn't belong in your .exrc file.
What version of vi are you using?
All versions I've ever seen allow you to type 1 (one) superfluous colon
at the start of an ex command.
And, frankly, I find myself doing that a lot when in ex mode.
--
Hans Mulder hansm@cs.kun.nl
From hansm@cs.kun.nl (Hans Mulder)
Subject: Re: vi macro def at startup
Date: 29 Jan 92 11:49:59 GMT
Status: O
In <1992Jan26.214411.795@swsrv1.cirr.com> mike@swsrv1.cirr.com (Mike Haddon) writes:
>I am doing this in my .exrc file as:
>map P :t dd
>where P is the macro identifier to use when you want to execute the macro
>and it works pretty well.
When I try that, vi says "t requires a trailing address".
Wouldn't it be better to write:
map P :t 'd ^M
[As always, getting a ^M requires typing control-V control-M.]
--
Hans Mulder hansm@cs.kun.nl
From soh@andromeda.trl.OZ.AU (Kam Hung Soh)
Subject: Re: .exrc location(s)
Date: 29 Jan 92 21:29:41 GMT
Status: O
jos@and.nl (Jos Horsmeier) writes:
>In article <1992Jan24.001030.8749@samba.oit.unc.edu> uevans@med.unc.edu (Elizabeth A. Evans) writes:
>|Well, I knew this a while back and then didn't fiddle with vi macros
>|for a while, and now I'm back at them. To create a vi macro, I
>|create a file called .exrc with the macro(s) defined in it, right?
>|So why am I finding that the file has to be in (or linked to) every
>|subdirectory I'm in during a vi session? Is there some other way
>|I should do it?
[ Jos quotes from the Sun vi man page ... ]
>It simply doesn't work that way. Vi (with SunOS 4.1.1.) just checks
>the cwd for .exrc, *not* the ~/ dir.
On my system (SparcStation 1+, SunOS 4.1.1), vi reads .exrc in the
present directory, AND .exrc in my home directory.
If the EXINIT environment variable is defined, vi will use that
variable and only .exrc in the present directory, ignoring .exrc in my
home directory.
Regards,
---
Soh, Kam Hung | h.soh@trl.oz.au | Telecom Research Laboratories,
| +61 3 253 6638 | POB 249 Clayton, Victoria 3168, Australia
From marzouki@rhone.imag.fr (Meryem Marzouki)
Subject: Re: vi macro def at startup
Date: 29 Jan 92 10:03:34 GMT
Status: O
In article <1992Jan26.185742.11545@jpradley.jpr.com> jpr@jpradley.jpr.com (Jean-Pierre Radley) writes:
>In article <sjreeves.920125112507@eng.auburn.edu> sjreeves@eng.auburn.edu (Stan Reeves) writes:
>>I want to define a macro in my ~/.exrc file, but it doesn't seem to work.
>>For example, I put
>>
>>:map t dd
>>
>>in the ~/.exrc file to test it, and it doesn't take. I don't have another
>>.exrc file in the directory I was using. Any ideas?
>One little colon!
>If you're already inside 'vi', then typing
> :map t dd
>would map 't' to 'dd'.
>But that ':' doesn't belong in your .exrc file.
It also works in the ~/.exrc file ! This macro (and any macro) syntax is
the same if you are either inside vi or if it's a line of your .exrc.
The only difference is that in the first case, the macro is no longer
valid after your current vi session.
Meryem MARZOUKI - Groupe Architecture des Ordinateurs - Lab TIM3/IMAG INPG
Tel. (+33) 76 57 46 96 - Fax. (+33) 76 47 38 14
46 avenue Felix Viallet - 38031 Grenoble Cedex - France
Internet : marzouki@archi.imag.fr - Bitnet : marzouki@frcime51.bitnet
Newsgroups: comp.editors
From jjj@mits.mdata.fi (Joni Jarvenkyla)
Subject: Octal code quotation in vi search & replace?
How to quote octal codes to vi seach & replace command
(%s/string1/string2/g)?
Problem is that I've got a file with octal codes \204 and \244 which
should get translated to ascii characters { and |.
--
jjj@mits.mdata.fi "Miks mun pit{is olla vastuussa jos t{{lt{
jjj@niksula.hut.fi l|ytyy jotain vitun irtop{it{?"
-Kari Nenonen, "Ken Kuolleita Kutsuu"
From beaty@aberdeen.FtCollins.NCR.com (Steve Beaty)
Subject: Re: .exrc location(s)
Date: 31 Jan 92 16:42:00 GMT
Status: O
uevans@med.unc.edu (Elizabeth A. Evans) writes:
> Well, I knew this a while back and then didn't fiddle with vi macros
> for a while, and now I'm back at them. To create a vi macro, I
> create a file called .exrc with the macro(s) defined in it, right?
i recently was dorking around with this stuff and realized that i
wanted to change my mappings based on the type of file i was editing.
i wrote the following csh file to do this:
----------------------------------------------------------------------
#! /bin/csh -f
set suffix = $argv[1]:e
if (-e ~/.exrc.$suffix) then
/usr/ucb/vi +":so ~/.exrc.$suffix" $argv
else
/usr/ucb/vi $argv
endif
----------------------------------------------------------------------
what this does is search in my home directory for files like ".exrc.c"
and ".exec.tex" for mappings for C and TeX source file mappings. i
then just place my generic stuff in .exrc and the source-specific
stuff in the additional .exec.*. if there isn't an associated file,
it just runs with the generic arguments. pretty handy. one problem i've
found is that vi doesn't seem to source the extra .exrc's when editing
an empty file. oh well.
Steve Beaty Steve.Beaty@ftcollins.ncr.com
Advanced Development beaty@longs.lance.colostate.edu
NCR Microelectronics (303) 226-9622 (palinphone)
"What You See Is What You Get, but it sure ain't what we need." Talking Heads

1456
comp.editors/ced.tips.5 Normal file
View File

File diff suppressed because it is too large Load Diff

950
comp.editors/ced.tips.6 Normal file
View File

@ -0,0 +1,950 @@
From tab@ibmpcug.co.uk (Andrew Beattie)
Subject: regular expression puzzle
Date: 2 Mar 92 18:14:01 GMT
I want to be able to take this input:
-----------------------------------------------------------------------------
some text [delete_this_bit ] some more text
-----------------------------------------------------------------------------
and change it to this:
-----------------------------------------------------------------------------
some text [ ] some more text
-----------------------------------------------------------------------------
By specifying that I want to replace all the characters within the "[]"
delimeters with spaces. Can it be done in one shot with a regular
expression? I am currently doing it one character at a time, thus:
-----------------------------------------------------------------------------
sed '
:again
s/\(\[ *\)[a-zA-Z_0-9]/\1 /
t again
'
-----------------------------------------------------------------------------
but surely there must be a neater way?
Andrew
--
From gummitch@techbook.com (Jeff Frane)
Subject: vi question--scrambled long lines
Summary: How to deal with over-long lines?
Keywords: vi
Date: 2 Mar 92 18:33:11 GMT
Two questions, really.
1 Does anyone have any good vi documentation they can e-mail me? I
have no way of retrieving anything by ftp.
2 What can I do about lines that get mangled when I attempt to reply,
either to e-mail or to a posting. These seem to occur when the original
writers are working on a wide terminal. The resulting lines get chopped
off, or worse, the terminal here starts writing lines way over on the
right margin.
--Jeff Frane
--
gummitch@techbook.COM Public Access UNIX at (503) 644-8135 (1200/2400)
"You must allow that drunkenness, which is equally destructive to body
and mind, is a fine pleasure." Lord Chesterfield, writing to his son
From jtwiss@isis.cs.du.edu (Justin Twiss)
Subject: Vi query
Summary: Help with a VI Search command
Keywords: vi search vowels
Date: 29 Feb 92 14:28:22 GMT
Greetings one and all...
Just a quick question, one of my lecturers at tech has set me a smalkl
task that I'm having a bit pof a problem with...
Using VI's search commandss, create a serarch line that would only
locate words that started and ended with a vowel....
I've spent three weeks on this and have just about given up in disgust..
Any ideas?
Justin...
jtwiss@isis.cs.du.edu
From fitz@mml0.meche.rpi.edu (Brian Fitzgerald)
Subject: Re: Vi query
Keywords: vi search vowels
Date: Sun, 1 Mar 1992 06:14:44 GMT
Justin Twiss writes:
>Using VI's search commands, create a search line that would only
>locate words that started and ended with a vowel....
Try
/\<[aeiouAEIOU][^ tab]*[aeiouAEIOU]\> or,
/\<[aeiouAEIOU][a-zA-Z']*[aeiouAEIOU]\>
See ed(1). Adjust the middle [] to suit. Fails for single letter
words like "a" or "I". Sorry.
Brian
From krm@pri-mu.prime.com (Martin {martlbub} Kraegeloh)
Newsgroups: comp.unix.questions
Subject: Re: vi query
Date: 2 Mar 92 22:17:21 GMT
> Justin Twiss (<jtwiss@isis.cs.du.edu>) asks:
>
> Using VI's search commands, create a search line that would only
> locate words that started and ended with a vowel....
>
vi's regular expressions match start and end of word with \< and \> .
a word (let's say a string without tabs and blanks) starting and ending
with a vowel is
/\<[aeiou][^ ^I]*[aeiou]\>/
should w instead of W (in vi's syntax) be matched, use
/\<[aeiou][A-Za-z0-9_]*[aeiou]\>/
Regards
Martin
From ricky@FibHaifa.com (Ricardo Marek)
Subject: `vi' without `stty crt -tabs' gets crazy (Help!)
Date: 2 Mar 92 16:56:49 GMT
In our site, there are a few users that still use `vi' as default editor.
But.. then, the user needs to run `stty crt -tabs' after he got login, so
`vi' doesn't get @#$%.
I know that the solution may be, using, `tset' command, but I didn't get
the correct results..
Any hints will be helpfull and apreciated.
(Please answer via e-mail, or posting to comp.sys.sun.*)
--- Ricky
--
Ricardo (Ricky) Marek (System Mng.)
Fibronics Ltd., Matam Industrial Park, Haifa 31905, ISRAEL
phones: +972-4-313690/670 Fax: +972-4-550550
e-mail: ricky@FibHaifa.com or ricky@fibronics.UUCP
From davis@shasta.bu.edu ("John E. Davis")
Subject: Tabs and Blanks: an experiment
Date: 2 Mar 92 23:27:55 GMT
Reply-To: davis@amy.tch.harvard.edu (John E. Davis)
There has been alot of discussion about tabs vs spaces. Here I present an a
numerical argument in favor of 8 column tabs. But first, let me throw in a
subjective statement.
First of all, there seems to be almost universal agreement that tabs should be
eight columns. Most devices assume this. Right or wrong this is the way it
is. Of course the good ones allow the user to specify what the tabs are.
Usually there is a command to set up tabs to 8 columns automatically. I have
never seen one with an option of 4 column tabs. So it seems to be a good idea
to stick with 8 column tabs. Many people prefer 4 column tabs for indentation
purposes. In my opinion, this is an editor limitation. A good editor will
indent the proper amount for you--- the tab key is usually bound to the indent
command.
The only real argument that one can make about tab size is based on the
resulting file size. If four column tabs produce a smaller file size than
eight column, then I'd say that we should adopt 4 column tabs. I propose a
method to find out:
let t be the tab size (4,8 or whatever).
let d be the indentation of the line that one produces by using tabs and
spaces.
Obviously, the number of tabs and spaces, n, for a given indentation, d, is
given by:
n(d,t) = d - (d/t) * (t - 1)
Here I am using integer arithmetic. Now suppose that the probability of an
indentation d is p(d). Then the average number of tabs and spaces <n> for an
arbitrary line is given by:
<n(t)> = sum_d { p(d) * n(d,t) }
This gives the average number of tabs and spaces for a given tab size t. Thus
one only minimize this with respect to t to determine the optimal tab size.
The only undetermined quantity is the probability distribution p(d). One can
get some idea of what ths is by examing many files and constructiong the
distribution. This will also depend on the indentation used by the person and
on what one calls the tab size. In the following, I consider equal
probalities. That is I take p(d) a constant.
Then consider the program:
#include <stdio.h>
main()
{
int sum, i, t, n;
t = 1;
while (t < 50)
{
sum = 0;
for (i = 1; i < 80; i++)
{
n = i / t;
sum += i - n * (t - 1);
}
printf("%d %d\n", t, sum);
t++;
}
}
with the output
1 3160
2 1600
3 1106
4 880
5 760
6 690
7 652
8 640
9 632 <-------- optimal choice
10 640
11 640
12 652
13 676
14 690
15 710
16 760
17 760
18 780
19 820
20 880
21 880
22 892
23 916
24 952
25 1000
.
.
.
47 1642
48 1656
49 1672
So as you can see, the optimal amount for equal probabilities is at t = 9.
--John
davis@amy.tch.harvard.edu
From davis@shasta.bu.edu ("John E. Davis")
Newsgroups: comp.editors
Subject: Re: Tabs and Blanks: an experiment
Date: 3 Mar 92 00:46:29 GMT
Reply-To: davis@amy.tch.harvard.edu (John E. Davis)
In the previous article, I wrote a program for which I assummed equal
probabilities. This is not really true. I really assumed that
p(d) = const != 0 for d < 80 and 0 otherwise
Here the cutoff was 80. Making the cutoff bigger will give greater tab sizes
and making it less will produce smaller ones.
It seems difficult to calculate p(d). As I said earlier, it depends on what
one chooses for the tab size. This is just another reason for conformance to
a standard.
Still, I find it interesting if someone writes a sed, awk or whatever script
that calculates p(d) for a large number of files using 8 column tabs with the
assumption that this is most common.
In fact we can play the same game as earlier:
Take a poll to find the probability q(t) that one uses tab size t. It will
most likely be peaked at 8 with a small bump at 4. Then fold this probability
into the calculation of p(d). That is, calculate p(d;t) using tab size t by
examing a ton of files with the above script. Then define
p(d) = sum_t { p(d;t) * q(t) }
and use the result in the calculation of the previous article.
--John
davis@amy.tch.harvard.edu
From peter@ferranti.com (peter da silva)
Subject: Re: Tabs and Blanks
Organization: Xenix Support, FICC
Date: Fri, 28 Feb 1992 18:59:48 GMT
In article <3200@ecicrl.ocunix.on.ca> clewis@ferret.ocunix.on.ca (Chris Lewis) writes:
> What's wrong with this is that it rules out coding styles that use
> indentation that's not always constant. [...]
> if ((blah blah.....) +
> (blah blah blah) -
> ....
> )
Ah, but I *use* that sort of thing, and I still use the "tab indent adjust
tabstops" trick as well. The point is, this isn't a new block so I don't want
to treat it as an indent.
> You can't use pure tabs for this. In fact, you can't adjust tab width
> at all without losing the logical layout.
Somehow that never seems to be a problem in practice.
--
-- Peter da Silva, Ferranti International Controls Corporation
-- Sugar Land, TX 77487-5012; +1 713 274 5180
-- "Have you hugged your wolf today?"
From peter@ferranti.com (peter da silva)
Newsgroups: comp.editors
Subject: Re: Tabs and Blanks: an experiment
Date: Tue, 3 Mar 1992 18:01:27 GMT
In article <DAVIS.92Mar2182755@shasta.bu.edu> davis@amy.tch.harvard.edu (John E. Davis) writes:
> The only real argument that one can make about tab size is based on the
> resulting file size.
That's just plain not true. Se previous discussions about dynamically changing
tab sizes for details.
--
-- Peter da Silva, Ferranti International Controls Corporation
-- Sugar Land, TX 77487-5012; +1 713 274 5180
-- "Have you hugged your wolf today?"
From einari@rhi.hi.is (Einar Indridason)
Subject: Re: Tabs and Blanks
Date: 6 Mar 92 09:55:41 GMT
In <1992Feb27.100149.20048@uwasa.fi> ts@uwasa.fi (Timo Salmi) writes:
>In article <1992Feb26.005954.4468@monu6.cc.monash.edu.au> steve@monu6.cc.monash.edu.au (Steve Balogh (+61 3 565 4747)) writes:
>>The FIRST thing I do when I obtain some "new" source code is to replace all
>>tabs with spaces. I HATE TABS in source code. They seem to make editing and
>>reformating much harder than it needs to be.
>So do I. If you are using a PC you might be interested in
Humm. This seems to be turning to a (dare I mention it?) Holy war?
My philosofi in this matter is to try to be consistent in indention style.
I sometimes get a source that is indented in a very wierd way. Most of the
time, it is better to follow the current indention style, whether it uses
spaces or tabs, rather than fix the whole source to fit your own
indention style.
However, in my own source I use tabs for indenting (no email flames about
that, please)
I can adjust the tabsize to a number I like. I usually keep the tab set at
8, but sometimes I set it to 4.
I find it a good indicator that a program needs re-structuring, if a line
goes beond the ~40th column, with a tabsize of 8.
Humm. And while I'm writing this, I have one question:
When is the next version of elvis to appear? (And how many bugs will
remain :-)
--
Internet: einari@rhi.hi.is | "Just give me my command line and drag
UUCP: ..!mcsun!isgate!rhi!einari | the GUIs to the waste basket!!!!"
Surgeon Generals warning: Masking the 8th bit can seriously damage your brain!!
From hartman@ulogic.UUCP (Richard M. Hartman)
Subject: Re: Tabs and Blanks
Date: 7 Mar 92 00:10:26 GMT
In article <1992Feb26.005954.4468@monu6.cc.monash.edu.au> steve@monu6.cc.monash.edu.au (Steve Balogh (+61 3 565 4747)) writes:
>In article <3157@ecicrl.ocunix.on.ca> clewis@ferret.ocunix.on.ca (Chris Lewis) writes:
>> Futzing around with non-8 tab widths is a fools game. It can
>> turn mild-mannered system integrators into screaming maniacs.
>> (Speaking as one who has screamed more than once ;-)
>
>The FIRST thing I do when I obtain some "new" source code is to replace all
>tabs with spaces. I HATE TABS in source code. They seem to make editing and
>reformating much harder than it needs to be.
>
>Anyway it works for me. :)
>
>Steve
>
I am suprised at all of you. One of the first sets of utility
programs I ever wrote are called "tabex" and "retab". The tabex
expands all tabs found in a file into the correct number of spaces.
(Taking into account nasty little things like space-tab combinations,
I actually count the columns & calculate tab-stops instead of doing
a simple substitution). "Retab" does just the opposite. Converting
all spaces possible into tabs using the spacing given. With these
two programs it is a simple matter to convert text from any tabbing
convention to the one you like (and back). All this fuss over nothing!
-Richard Hartman
hartman@uLogic.COM
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Extensive studies have shown that 93% of all statistics are meaningless.
From gummitch@techbook.com (Jeff Frane)
Subject: vi question--scrambled long lines
Summary: How to deal with over-long lines?
Keywords: vi
Date: 2 Mar 92 18:33:11 GMT
Two questions, really.
1 Does anyone have any good vi documentation they can e-mail me? I
have no way of retrieving anything by ftp.
2 What can I do about lines that get mangled when I attempt to reply,
either to e-mail or to a posting. These seem to occur when the original
writers are working on a wide terminal. The resulting lines get chopped
off, or worse, the terminal here starts writing lines way over on the
right margin.
--Jeff Frane
--
gummitch@techbook.COM Public Access UNIX at (503) 644-8135 (1200/2400)
"You must allow that drunkenness, which is equally destructive to body
and mind, is a fine pleasure." Lord Chesterfield, writing to his son
From vic@class.gsfc.nasa.gov (Vic Ryan)
Subject: Re: Tabs and Blanks
Date: Sat, 7 Mar 1992 11:45:28 GMT
hartman@ulogic.UUCP (Richard M. Hartman) writes:
>In article <1992Feb26.005954.4468@monu6.cc.monash.edu.au> steve@monu6.cc.monash.edu.au (Steve Balogh (+61 3 565 4747)) writes:
>>In article <3157@ecicrl.ocunix.on.ca> clewis@ferret.ocunix.on.ca (Chris Lewis) writes:
>>> Futzing around with non-8 tab widths is a fools game. It can
>>> turn mild-mannered system integrators into screaming maniacs.
>>> (Speaking as one who has screamed more than once ;-)
>>
>>The FIRST thing I do when I obtain some "new" source code is to replace all
>>tabs with spaces. I HATE TABS in source code. They seem to make editing and
>>reformating much harder than it needs to be.
>>
>>Anyway it works for me. :)
>>
>>Steve
>>
>I am suprised at all of you. One of the first sets of utility
>programs I ever wrote are called "tabex" and "retab". The tabex
>expands all tabs found in a file into the correct number of spaces.
>(Taking into account nasty little things like space-tab combinations,
>I actually count the columns & calculate tab-stops instead of doing
>a simple substitution). "Retab" does just the opposite. Converting
>all spaces possible into tabs using the spacing given. With these
>two programs it is a simple matter to convert text from any tabbing
>convention to the one you like (and back). All this fuss over nothing!
GREAT....!!!! Where does one get these wonderful utilties ?????
---------------------------------------------------------------
Thanks, Vic
From peter@ferranti.com (peter da silva)
Newsgroups: comp.editors
Subject: Re: Tabs and Blanks
Date: 9 Mar 92 19:13:47 GMT
In article <26@ulogic.UUCP> hartman@ulogic.UUCP (Richard M. Hartman) writes:
> With these
> two programs it is a simple matter to convert text from any tabbing
> convention to the one you like (and back). All this fuss over nothing!
OK, I'll check a file out of SCCS, convert it to my tab format, edit it,
and check it back in. You do the same. Let's see how quickly we can run out
of disk space.
--
-- Peter da Silva, Ferranti International Controls Corporation
-- Sugar Land, TX 77487-5012; +1 713 274 5180
-- "Have you hugged your wolf today?"
From Marc_North@mindlink.bc.ca (Marc North)
Subject: Re: VI Limitations
Date: 10 Mar 92 17:45:53 GMT
> Rich Thompson writes:
>
> Yesterday when I was editing a file using VI, I was given an error
> saying the line I was using was too long. Is there anyway to get
> around this? The line I was editing needed to be extremely long
> and I ended up having to use emacs for that particular file.
Well, to the best of my knowledge, there isn't.
If you want, I can send you a program that will chop all overly long lines to a
nice, respectible 77 characters. It's not great on formatting, but it does take
tabs equal to eight spaces into consideration. Email me and I will send.
Marc
--
Marc North -- ULYSSES Systems Corporation (USC)
From wuth@imhfhp16.epfl.ch (WUTHRICH Serge IMHEF DME EPFL)
Subject: vi with X-window features
Date: 11 Mar 92 12:14:46 GMT
Has somebody seen a verion of vi with full X-window extension like
use of the mouse to cut/paste/delete/scroll/etc. ?
Thanks,
Serge
-----
S.Wuthrich
wuth@dme.epfl.ch
From steve@monu6.cc.monash.edu.au (Steve Balogh (+61 3 565 4747))
Newsgroups: comp.editors
Subject: Re: Tabs and Blanks
Date: 12 Mar 92 01:52:13 GMT
In article <1992Feb26.005954.4468@monu6.cc.monash.edu.au> steve@monu6.cc.monash.edu.au (Steve Balogh (+61 3 565 4747)) writes:
>
>The FIRST thing I do when I obtain some "new" source code is to replace all
>tabs with spaces. I HATE TABS in source code. They seem to make editing and
>reformating much harder than it needs to be.
>
I suppose I should be fair and say that there are other reasons that I "fix up"
source code in this manner. Yes, I do remove TABS, but I also change other
aspects of the program layout such as the placing of { and } characters, the
spacing between items on a line, and so on. I also add many comments as I
discover what particular sections of code do.
I find that by going through a program in such a way gives me a better idea of
how it works. I suppose it is similar to taking notes during lectures by helping
you remember the facts. Anyway, it works for me.
Steve
----_--_-_-_--_-__-_------_-__---_-___-_----_-____-_-_--__-_--_--___-_-_-_--__-_
Steve Balogh VK3YMY (Maths G.14) | steve@monu6.cc.monash.edu.au
Monash University, Clayton Campus | 37 54'38.8"S 145 07'47.1"E ...ICBM
Wellington Road, Clayton. | +61 3 565 4747 Voice (Office)
Melbourne, AUSTRALIA. 3168 | +61 3 565 4746 Fax
From gregm@otc.otca.oz.au (Greg McFarlane)
Newsgroups: comp.editors
Subject: Using the vi -c command line option
Date: 12 Mar 92 23:54:11 GMT
On my system, the command:
vi -c ":set ic" -c /greg file
does not work. I expected it to set the ignorecase flag and then edit "file"
stopping at the first occurrence of [Gg][Rr][Ee][Gg]. However, the :set command
seems to be ignored. The following commands work as expected:
vi -c ":set ic" file
vi -c /greg file
Any suggestions as to what I am doing wrong?
I am using a Sparc, SunOS 4.1.
Greg
--
ACSnet: gregm@otc.otca.oz.au
Greg McFarlane UUCP: {uunet,mcvax}!otc.otca.oz.au!gregm
|||| OTC || Snail: OTC R&D GPO Box 7000, Sydney 2001, Australia
Phone: +61 2 287 3139 Fax: +61 2 287 3299
From heroux@cemmva.cem.msu.edu (Brett J. Heroux)
Subject: re: vi command line thing
Date: 13 Mar 92 05:17:36 GMT
Lines: 7
Multiple comands on the command line, hmmm. I tried
vi ":set ic | /see" tfile
and the editor started up at a line containg "sEE" in tfile.
Brett Heroux heroux@titan.cem.msu.edu
From hansm@cs.kun.nl (Hans Mulder)
Subject: Re: Using the vi -c command line option
Date: 13 Mar 92 14:26:17 GMT
In <5231@otc.otca.oz> gregm@otc.otca.oz.au (Greg McFarlane) writes:
>On my system, the command:
> vi -c ":set ic" -c /greg file
>does not work. I expected it to set the ignorecase flag and then edit "file"
>stopping at the first occurrence of [Gg][Rr][Ee][Gg]. However, the :set command
>seems to be ignored. The following commands work as expected:
> vi -c ":set ic" file
> vi -c /greg file
You're trying to pass two commands via the -c interface, and it accepts
only one. You should combine the commands using the '|' separator instead:
vi -c ":set ic | /greg" file
Notes:
1. The ':' is optional.
2. You can abbreviate "-c " to "+", i.e.
vi +"set ic|/greg" file
also works.
3. The default is "-c 1", i.e. start at the top of the buffer, rather
than at the bottom (the ex default). Using an explicit "-c" or "+" on
the command line overrules the default. As a result the search starts
at the last line. That's OK for a forward search, but
vi +"set ic|?greg" file
would overlook an occurrance of "Greg" on the last line.
You've probably noticed that
vi -c ":set ic" file
starts at the last line. Use
vi -c ":set ic | 1" file
or
vi +"set ic|1" file
if you prefer to start at the top.
--
Hope this helps,
Hans Mulder hansm@cs.kun.nl
From ant@mks.com (Anthony Howe)
Subject: Re: Using the vi -c command line option
Date: Fri, 13 Mar 1992 23:05:23 GMT
hansm@cs.kun.nl (Hans Mulder) writes:
[....]
>
>Notes:
>1. The ':' is optional.
>2. You can abbreviate "-c " to "+", i.e.
> vi +"set ic|/greg" file
Note that the +command option is obsolescent in POSIX.2a. To me that
means +command may disappear at some point in the future. If you're not
in the habit now of using +, stick with -c so that when you move to
systems with POSIX conforming VI, you don't get caught by a vendor who
decided to drop obsolescent forms.
>also works.
[...]
--
ant@mks.com Anthony C Howe
Mortice Kern Systems Inc. 35 King St. N., Waterloo, Ontario, Canada, N2J 6W9
"Congratulations, you've reached 10cm dilation. You may now give birth." - Worf
From sid@knoblake.sybase.com (sid cowles)
Newsgroups: comp.editors
Subject: Re: Using the vi -c command line option
Date: 15 Mar 92 18:00:45 GMT
In article <5231@otc.otca.oz>, gregm@otc.otca.oz.au (Greg McFarlane) writes:
|> On my system, the command:
|> vi -c ":set ic" -c /greg file
|>
|> does not work. I expected it to set the ignorecase flag and then edit "file"
|> stopping at the first occurrence of [Gg][Rr][Ee][Gg].
...
|>
|> Any suggestions as to what I am doing wrong?
|>
|> I am using a Sparc, SunOS 4.1.
the following places the cursor on the first line with the searched for
regexp: vi -c ":set ic|/greg" file
where the vertical bar is used to separate the two commands.
sid cowles
voice: +1-510-596-3971
internet: uucp:
sid@sybase.com {pacbell,sun,{uunet,ucbvax}!mtxinu}!sybase!sid
scowles@llnl.gov {backbone}!lll-winken!humpty!scowles
From Marc_North@mindlink.bc.ca (Marc North)
Subject: Re: VI Limitations
Date: 10 Mar 92 17:45:53 GMT
> Rich Thompson writes:
>
> Yesterday when I was editing a file using VI, I was given an error
> saying the line I was using was too long. Is there anyway to get
> around this? The line I was editing needed to be extremely long
> and I ended up having to use emacs for that particular file.
Well, to the best of my knowledge, there isn't.
If you want, I can send you a program that will chop all overly long lines to a
nice, respectible 77 characters. It's not great on formatting, but it does take
tabs equal to eight spaces into consideration. Email me and I will send.
Marc
--
Marc North -- ULYSSES Systems Corporation (USC)
From gordon@osiris (John Gordon)
Subject: Vi message 'Where are you?' from !}fmt command - huh?
Keywords: vi,where,are,you
Date: 18 Mar 92 15:32:05 GMT
We have a user who, when she does a !}fmt command in vi, gets the text
'Where are you?' entered into her document. She says that it just started
happening recently. I saw it happen, and checked her path, aliases, and did
a 'strings' on vi and fmt, but no luck. Anyone out there have an idea?
She is working on a Sun SPARC workstation.
John Gordon
gordon@osiris.cso.uiuc.edu
From hansm@cs.kun.nl (Hans Mulder)
Subject: Re: Vi message 'Where are you?' from !}fmt command - huh?
Keywords: vi,where,are,you
Date: 18 Mar 92 19:07:27 GMT
In <1992Mar18.153205.24581@ux1.cso.uiuc.edu> gordon@osiris (John Gordon) writes:
> We have a user who, when she does a !}fmt command in vi, gets the text
>'Where are you?' entered into her document. She says that it just started
>happening recently. I saw it happen, and checked her path, aliases, and did
>a 'strings' on vi and fmt, but no luck. Anyone out there have an idea?
She recently put
biff y
in the wrong part of her ~/.cshrc file. It should have been between the lines
if ($?prompt) then
and
endif
and it isn't. If her .login gets sourced when she logs in, she should move
it there, otherwise should put it between those lines. Or, if there aren't
any such lines, she could abbreviate it
if ($?prompt) biff y
or if she uses a shell with a sane syntax, she would say
if [ $# = 0 ]
then biff y
fi
or
if [ $# = 0 ]; then biff y; fi
in the file that she put the "biff y" in.
--
Hans Mulder hansm@cs.kun.nl
From shj@login.dkuug.dk (Stig Jacobsen)
Subject: Re: vi puzzler ..
Date: 22 Mar 92 13:43:08 GMT
sriram@alka.tcs.com (Sriram Srinivasah) writes:
>If I am editing file <x>.c, how do I, with one keystroke, edit file <x>.h ?
>Is there some way of getting the output of 'file' or '%' into a buffer ?
:e `basename % .c`.h
I suppose that this can be bound to a key with map, but I'm not
familiar enough with it to tell you how.
--
Stig Jacobsen Born confused
shj@login.dkuug.dk Died dazed
From dave@csd4.csd.uwm.edu (David A Rasmussen)
Subject: vi startup in insert mode?
Date: 21 Mar 92 17:12:11 GMT
Um, someone last week or so posted an article, apparently not in this group
on how to start up vi in insert mode. I didn't save the article, and now
wanted to see how they did that.
Also, if I define a macro in my joverc file, and I try to auto-execute-macro
it, I get an error about recursion. Anyone have a suggestion for me with
this?
thx in advance.
--
Dave Rasmussen - Systems Programmer/Manager, UW-Milwaukee Computing Svcs Div.
Internet:dave@uwm.edu, Uucp:uwm!dave, Bitnet:dave%uwm.edu@INTERBIT
AT&T:414-229-5133 USmail:Box 413 EMS380,Milwaukee,WI 53201
From sriram@alka.tcs.com (Sriram Srinivasah)
Subject: vi puzzler ..
Date: 21 Mar 92 18:55:40 GMT
If I am editing file <x>.c, how do I, with one keystroke, edit file <x>.h ?
Is there some way of getting the output of 'file' or '%' into a buffer ?
Sriram
(sriram@tcs.com)
From brandy@tramp.Colorado.EDU (BRANDAUER CARL M)
Subject: Re: vi puzzler ..
Date: 22 Mar 92 18:56:13 GMT
sriram@alka.tcs.com (Sriram Srinivasah) writes:
>If I am editing file <x>.c, how do I, with one keystroke, edit file <x>.h ?
>Is there some way of getting the output of 'file' or '%' into a buffer ?
Start your editing session with:
vi <x>.c <x>.h
After you have finished with <x>.c the first time, type
:n
to edit <x>.h. After the first go around, CTRL-^ will let you
alternate between the two files.
Cheers
From shj@login.dkuug.dk (Stig Jacobsen)
Subject: Re: vi puzzler ..
Date: 22 Mar 92 13:43:08 GMT
sriram@alka.tcs.com (Sriram Srinivasah) writes:
>If I am editing file <x>.c, how do I, with one keystroke, edit file <x>.h ?
>Is there some way of getting the output of 'file' or '%' into a buffer ?
:e `basename % .c`.h
I suppose that this can be bound to a key with map, but I'm not
familiar enough with it to tell you how.
--
Stig Jacobsen Born confused
shj@login.dkuug.dk Died dazed
From soh@andromeda.trl.OZ.AU (Kam Hung Soh)
Subject: Re: vi puzzler ..
Date: 24 Mar 92 22:35:24 GMT
sriram@alka.tcs.com (Sriram Srinivasah) writes:
>If I am editing file <x>.c, how do I, with one keystroke, edit file <x>.h ?
>Is there some way of getting the output of 'file' or '%' into a buffer ?
Try this macro:
map CHAR :e `basename % .c`.h^M
% is the current file name.
basename returns a string without the suffix found in the second argument.
`...` returns the result of some command.
You can now toggle between the two files using CTRL-^.
Mind you, starting vi with both filenames would be easier. In [t]csh:
$ vi x.[ch]
Regards,
--
Soh, Kam Hung, Network Management Research, | h.soh@trl.oz.au
TRL, POB 249 Clayton, Victoria 3168, Australia | +61 3 253 6638
From tgcpmv@rwa.urc.tue.nl (Martien Verbruggen)
Subject: case macros in vi ?
Keywords: case, vi, macro
Date: 30 Mar 92 10:04:51 GMT
Hello,
I got some macros from an anonymous ftp-site, which should alter the
case of a word and a line in vi. the macro for the line works allright,
but the macro for the word ( using the macro for the line ) doesn't.
The macro' are as follows:
" shift case down for word
map _l mzywop0_Ldw`zPwdwjddk
" shift case down for line
map _L :s/\([A-Z]*\)/\L\1/g
It seems that the macro for the word went wrong at the p. When I type it
in by hand it works allright. Can anyone help me out ?
--
Martien Verbruggen
Eindhoven University of Technology
The Netherlands.
--
Yesterday I thought I was insecure.....
Today I'm not so sure anymore.

97
comp.editors/ced.tips.Inx Normal file
View File

@ -0,0 +1,97 @@
This file contains the INDEX of the Comp.Editor tips collection.
The index is created by running a grep(1) on the Subject.
The various tips files can easily be acessed via the standard Berkeley
mailinterface:
mail -f ced.tips.1
When I have the time, I exstract some of the subject presents, and put
them in separate files. But this will probably not happen before
easter '92 ;-).
ced.tips.1
In vi: How to delete from str1 to str2 ?
In vi: How do I put line numbers in frant of each line ?
writing from buffers
How to disable 'vi' beep?
Tabs as spaces in VI.
vi question - am I so different?
vi question, replace second occurence
removing first field from a number of lines with vi
Smart 'C' editors?!?
vi question, replace second occurence
filling paragraph in vi
ced.tips.2
Quoting in ex/vi -- more info
Vi and Tags file...(please help).
piping in an ex keymap
EX / VI delete up-to and including
What does this do? (was Vi internal design doc. needed)
Fun with tags
VI search for begin/end of blocks
how do I macroize c --> |c|
Addressing lines in vi and ex
ced.tips.3
Using shell filters in VI
VI: Freeing macro space for map command
How do do these things in vi?
How do you do these things in vi?
vi window scrolling
How to change timeout length in vi without timeoutlen ?
ctrl-u in vi
vi window scrolling (vt100)
Reverse video in vi
Going crazy with non-vi DOS editor
ex command to delete blank lines
vi (including file name)
ced.tips.4
vi (including file name)
VI: Changing case for an entire word...how did I do it?
How do I... (vi or awk question, perhaps?)
.exrc location(s)
vi macro def at startup
Octal code quotation in vi search & replace?
ced.tips.5
Good names for vi macros
do I ignorecase when using a TAGs file?
Tabs and Blanks
easy vi question: how to 'grep -v /r.e/'
vi question
vi - redefine <TAB>-key with <BLANK><BLANK>
wanted: ms-dos vi
macro record and playback in vi?
vi ! command in non-interactive envt.
VI - Number of Lines
vi and terminal emulation vt102 ???
VI terminal type
Bug in elvis?
ced.tips.6
regular expression puzzle
vi question--scrambled long lines
Vi query
`vi' without `stty crt -tabs' gets crazy (Help!)
Tabs and Blanks: an experiment
Tabs and Blanks
VI Limitations
vi with X-window features
Using the vi -c command line option
vi command line thing
Using the vi -c command line option
Vi message 'Where are you?' from !}fmt command - huh?
vi startup in insert mode?
vi puzzler ..
case macros in vi ?
ced.tips.7
Problem with vi paste
Friendly vi for new users SUMMARY
"c," in vi
VI bug using X.
Buggy vi's

138
comp.editors/cmdline Normal file
View File

@ -0,0 +1,138 @@
From mgflax@phoenix.Princeton.EDU (Marshall G. Flax)
Subject: Re: Command line editing in vi
Date: 12 Aug 92 06:32:11 GMT
In article <1992Aug12.021145.5902@nuscc.nus.sg> ccechk@nuscc.nus.sg (Heng Kek) writes:
>Imagine entering something like
> :'a,$s/\([a-z]*\).*\([0-9]\) *[^ ]*)/\2,\1==/
>only to find that you've missed a '('.
>
>I hope there's an answer which I presume lies in macros.
One solution is to actually enter that line into your text and edit it
until it is perfect. Then yank it into a named buffer
"zdd
and execute it
@z
If you need to fix it, you can pull it back from the named buffer,
"zp
re-edit, re-yank, and then re-execute it.
marshall
--
------- (c) 1992, Marshall Gene Flax <mgflax@phoenix.Princeton.EDU> -------
----------- 5 Joyce Lane, Woodbury, NY 11797, 516-364-9331,9379 ----------
- c/o Jack Gelfand,Psychology Dept,Princeton U.,NJ 08544,609-258-6739 (w) -
From ccechk@nuscc.nus.sg (Heng Kek)
Subject: Command line editing in vi
Date: Wed, 12 Aug 1992 02:11:45 GMT
I've a feeling this question might have cropped up before. If so, I
apologise. How may I 'recall' the last cmd I entered in vi in such
a way that I can edit that command and execute it? Something like
the history command editing in tcsh.
This feature is real useful in situations when I enter a mistyped
command and want to reenter the corrected one. Imagine entering
something like ":'a,$s/\([a-z]*\).*\([0-9]\) *[^ ]*)/\2,\1==/" only
to find that you've missed a '('. It's not fun to retype the whole
thing. :)
I hope there's an answer which I presume lies in macros.
Kek
From stv@ferret.uucp (Steve Manning)
Subject: Re: Command line editing in vi
Date: 27 Aug 92 05:21:00 GMT
Article-I.D.: ferret.1992Aug27.052100.1716
In article <1992Aug12.021145.5902@nuscc.nus.sg> ccechk@nuscc.nus.sg (Heng Kek) writes:
> How may I 'recall' the last cmd I entered in vi in such
>a way that I can edit that command and execute it? Something like
>the history command editing in tcsh.
>
>This feature is real useful in situations when I enter a mistyped
>command and want to reenter the corrected one. Imagine entering
>something like ":'a,$s/\([a-z]*\).*\([0-9]\) *[^ ]*)/\2,\1==/" only
>to find that you've missed a '('. It's not fun to retype the whole
>thing. :)
Whenever I find that I'm going to be constructing a long pattern
such as the one you list, I will take advantage of vi's ability to
execute the contents of a named buffer as a macro. Typing the
AT-symbol ('@') followed by a letter (in command mode, of course)
will do this. Of course, this does require you to take steps before-
hand to do it and so is not "history command editing".
Simply type the command directly into the file on a line of its
own, delete the line into a named buffer ("add), and then execute
the contents of that buffer (@a). If there are any problems, simply
undo (u), replace the buffer into the file ("ap), edit, and repeat!
BTW, I've worked with older, buggier versions of vi and I've had
them drop the contents of the buffer I try to use if there are
certain types of errors in the command therein. So I've gotten in
the habit of yanking the command into two or more buffers before
I try to execute it, just in case.
Of course, you could also save the command in a file of it's own
and execute the file with the :source command. You shouldn't have
to worry about vi going out and erasing the contents of your command
file :-).
Enjoy!
--
Steve Manning stv%ferret@introl.introl.com stv@ferret.uucp
Milwaukee, WI ...!introl!ferret!stv etc., etc., etc.
"...but you're wrong, Steve. You see, it's only Solitaire" I.A.
From ian@unipalm.co.uk (Ian Phillipps)
Subject: Re: Command line editing in vi - a macro
Date: Wed, 2 Sep 1992 12:07:42 GMT
stv@ferret.uucp (Steve Manning) writes:
>In article <1992Aug12.021145.5902@nuscc.nus.sg> ccechk@nuscc.nus.sg (Heng Kek) writes:
>> How may I 'recall' the last cmd I entered in vi in such
>>a way that I can edit that command and execute it? Something like
>>the history command editing in tcsh.
>Whenever I find that I'm going to be constructing a long pattern
>such as the one you list, I will take advantage of vi's ability to
>execute the contents of a named buffer as a macro. Typing the
>AT-symbol ('@') followed by a letter (in command mode, of course)
>will do this. Of course, this does require you to take steps before-
>hand to do it and so is not "history command editing".
I find very useful the mapping:
:map <some key> ms"syy@s`s
Which uses buffer "s" and text mark "s". It obeys the current line as a
command, so that if I put a suitable command into the buffer, I can run
it. It returns the cursor to the same place using mark "s" - this is a
luxury item, but very useful if the command reads a file, for example.
I've had no troubles with the old or new SunOS vi (the "new" version
announces itself as SVR3.1).
I even went through a phase of using "vi" as my normal shell.
Example - the ":r!date" was typed in, then the "Insert" key pressed:
:r!date
Wed Sep 2 12:58:35 BST 1992
Ian
--

25
comp.editors/cols Normal file
View File

@ -0,0 +1,25 @@
From kevinl@tisdec.tis.tandy.com
Date: 18 Aug 92 09:08 CDT
Subject: Re: Switching cols in VI
If you don't want to worry about how many columns you have,
you can use the following awk program.
{
for( i = 0; i < NF; i++ ) {
printf "%s", $(NF - i)
if( i != NF - 1 )
printf " "
}
print ""
}
It just starts at the end and works backwards. The 'if' is there
so that it doesn't put spaces at the end of your lines. Hope this
helps you out. 8-)

28
comp.editors/columedit Normal file
View File

@ -0,0 +1,28 @@
From riskit@x400gate.bnr.ca (Reg Foulkes)
Subject: Re: Using vi to edit columns (was Re: Why I love VI)
Date: Thu, 13 Aug 1992 13:38:45 GMT
In article <Bsu0EG.73F@root.co.uk>, gwc@root.co.uk (Geoff Clare) wrote:
>
> In <riskit-100892113813@47.201.0.36> riskit@x400gate.bnr.ca (Reg Foulkes) writes:
>
> > My main objection is that you cannot use vi to edit columns.
>
> Which is why I wrote some macros to do "block delete and copy".
> They are available from the worldwide vi archive sites.
What, or more precisely where, are these worldwide vi archive sites?
Where is the closest one to Ottawa, Canada?
I would like to try these out, but first why would a block delete and
copy work? I would expect by the name that you block and copy rows, since
vi is a stream editor not columns.
***********************************
riskit@x400gate.bnr.ca (Reg Foulkes)
No passion on earth, no love or hate
Is equal to the passion
to change someone else's code

50
comp.editors/counter Normal file
View File

@ -0,0 +1,50 @@
From jimr@applix.com (Jim Rouleau [ext 256])
Subject: Counter in VI?
Date: 13 Aug 92 14:15:38 GMT
Is there any way to implement a counter in VI?
What I'd like to do is take something like this:
#define a 1
#define b 2
#define c 3
.
.
#define z 26
to become
#define a 0
#define b 1
#define c 2
.
.
#define z 25
Any way to do this besides manually??
jimr
From mgflax@phoenix.Princeton.EDU (Marshall G. Flax)
Subject: Re: Counter in VI?
Date: Thu, 13 Aug 1992 17:02:13 GMT
In article <1623@applix.com> jimr@applix.com (Jim Rouleau [ext 256]) writes:
>What I'd like to do is take something like this:
>
> #define z 26
> to become
> #define z 25
Pipe the relevant lines through awk! (Although, if you're really only
concerned with changing #defines, compilers will generate exactly the
same code given
#define z (26-1)
as if they received
#define z 25
and the addition of the parenthesis et.al. can clearly be done within vi.)
marshall
--
------- (c) 1992, Marshall Gene Fla

60
comp.editors/countwords Normal file
View File

@ -0,0 +1,60 @@
From cjlin@math.ntu.edu.tw ()
Subject: How to count words ?
Date: Sat, 3 Jul 1993 02:13:38 GMT
Dear netters :
Could someone tell me how to count the number
of words in Vi or under UNIX shell ?
Thanks in advance.
Chih-Jen Lin
Dept. of Math.
National Taiwan Univ.
From markhof@ls12r.informatik.uni-dortmund.de (Ingolf Markhof)
Subject: Re: How to count words ?
Date: 3 Jul 1993 12:15:30 GMT
In article <1993Jul3.021338.16304@ccds3.ntu.edu.tw>, cjlin@math.ntu.edu.tw () writes:
|> Could someone tell me how to count the number
|> of words in Vi or under UNIX shell ?
Yes, that's easy: Just type
:!wc -w % <CARRIGE RETURN>
in command mode to get the number of words, or
:!wc % <CARRIGE RETURN>
to get the number of lines, words and characters.
------------------------------------------------------------------------------
____
UniDo / Ingolf Markhof University of Dortmund, LS Informatik XII
___/ / PFrom hansm@wsinti06.info.win.tue.nl (Hans Mulder)
Subject: Re: How to count words ?
Date: 6 Jul 1993 21:51:42 +0200
In <1993Jul3.021338.16304@ccds3.ntu.edu.tw> cjlin@math.ntu.edu.tw () writes:
>Dear netters :
>Could someone tell me how to count the number
>of words in Vi or under UNIX shell ?
In vi:
:w !wc -w
^
^ this space is essential.
In the shell:
wc -w filename
HansM

62
comp.editors/crlf Normal file
View File

@ -0,0 +1,62 @@
From buboo@alf.uib.no (Ove Ruben R Olsen)
Subject: Re: How do I remove new-lines [CR,LF] in vi?
Date: Mon, 20 Jul 92 08:54:26 GMT
Sergio Stewart writes:
>How do I remove a CR,LF from a file while editing with vi?
>In the past Ive "dd" the entire line just to remove the CR,LF.
>I know it is possible to use "u" undo the CR,LF is still in the
>buffer, but what if it isnt? What Id like is a simple "x" [delete char]
>solution to removing CR and LF's.
>
>Any ideas?
To remove the CRLF at the end of a line: :%s/^V^M//
^
CTRL-V-CTRL-M
To remove blanklines (LF): :%s/^$//
^
NOT CTRL-$, but just ^ and $
To remove blanklines containing ^M (CRLF): :%s/^^V^M$//
\Ruben.
--
Ove Ruben R Olsen, Professional VI user. EMAIL: Ove.R.Olsen@ubb.uib.no
Maintaining the Largest VI/EX-STUFF Archive in the WORLD (alf.uib.no) and
the Comp.Editors FAQ file. If you have information about editing, new editors,
please get in touch with me. This does not apply to EMACS type of editors.
From hansm@cs.kun.nl (Hans Mulder)
Subject: Re: How do I remove new-lines [CR,LF] in vi?
Date: Mon, 20 Jul 1992 10:03:00 GMT
In <Brnt3s.5r6@x10siv.wariat.org> serges@x10siv.wariat.org (Sergio Stewart) writes:
>How do I remove a CR,LF from a file while editing with vi?
>In the past Ive "dd" the entire line just to remove the CR,LF.
If there are any CRs in the buffer (vi shows those as ^M), you can use
"x" to get rid of them.
The easiest way to get rid of an LF is usually "J" (join lines).
Vi tries to be smart about "J" and give you the appropriate amount
of white space instead. If you don't want that, you can "x" it out
or use ":j!" instead of "J" to stop vi from generating it.
--
Hope this helps,
Hans Mulder hansm@cs.kun.nl
From albani@cadlab.sublink.org (Lanfranco Albani)
Subject: Re: How do I remove new-lines [CR,LF] in vi?
Date: 21 Jul 92 09:35:58 GMT
buboo@alf.uib.no (Ove Ruben R Olsen) writes:
:To remove the CRLF at the end of a

62
comp.editors/cshline Normal file
View File

@ -0,0 +1,62 @@
From: fisher@inls1.ucsd.edu (Yuval Fisher)
Newsgroups: comp.editors
Subject: Vi/Ex: command line editor? - Yes!
Date: 16 Sep 92 17:14:48 GMT
Organization: Institute for Nonlinear Science
Lines: 54
Quite some time ago ian@unipalm.uucp (Ian Phillipps) wrote
about a handy way to set up a csh command line editor using vi.
I have been using it faithfully, until my vi changed from
"Version 3.7, 6/7/85." to "Version SVR3.1". Now, things are screwy
and it basically doesn't work. Does anyone know how to fix this
problem (other than switch away from csh or change vi) ? Incidentally,
I consider this command line editor thingy to be the best thing since,
say, money subplanted bartering ?
I include Ian's posting below, since it is short:
The following works with the C-shell. It was posted about two years ago
on Usenet, and the poster then said that its origin was lost in the
mists of time. Here goes:
You need an alias in your normal setup, thuswise:
alias r source ~/cmd/redo
Type "r" and you'll be in "vi" open mode, editing the last command. You can
use any vi/ex commands (even go into visual mode): when you hit Return, the
current line will be executed by the C shell.
The "redo" file is as follows. **IMPORTANT NOTE** To avoid mangling in
the posting, I've replaced a Carriage Return with "^M" and an ESC with "^["
in ex's "map" command:
----cut here and replace control characters---
# Edit history list at line containing last command (open mode).
# Get up to 22 most recent commands.
# To work properly, put in .login: alias r source /usr/local/bin/redo
# Author unknown.
history -h 22 >! /tmp/redo.$$
# Make CR map to :wq! and start ex quietly at 2nd to last line in open mode.
ex - '+map ^M :.wq\!^[|set redraw|$-1 open' /tmp/redo.$$
# Insert into history without executing.
source -h /tmp/redo.$$
# Clear out temporaries.
/bin/rm -f /tmp/redo.$$
# If thing chosen to redo is the redo alias itself then DON'T redo it.
if (!-2:0 != !!:0) !!
----cut here----
---------------------------------------------------------------------
Yuval Fisher e-mail: yfisher@ucsd.edu
Institute for Non-Linear Science 0402
University of California, San Diego
La Jolla, CA 92093
---------------------------------------------------------------------

136
comp.editors/ctrl Normal file
View File

@ -0,0 +1,136 @@
From govind@infonode.ingr.com (Govind Vadvadgi)
Subject: vi: How to type S and ^Q in ascii file?
Date: Wed, 22 Jul 1992 20:34:18 GMT
I was wondering if there is way to type Q ( Cntrl-Q ) and S ( Cntrl-S )
in an ascii file. ( I can type other charecters like , , etc. )
Thanks in advance.
--
-Govind.
govind@infonode.ingr.com
From hello@cs.utwente.nl (Ronald Hello)
Subject: Re: vi: How to type S and ^Q in ascii file
Reply-To: hello@cs.utwente.nl
Date: Wed, 29 Jul 1992 11:30:43 GMT
In article JFn@news.cso.uiuc.edu, gordon@osiris.cso.uiuc.edu (John Gordon) writes:
rh>
rh> In vi, to enter any control character, first type Control-V, then
rh>the desired control character. For example, to enter a Control-Y, you
rh>would type: Control-V Control-Y
Seems to me he asked especially about Control-Q and Control-S, not about your
average Control character. Try it on a Sun, in vi with Control-S. I posted this
as a question here some time ago and it seems it's NOT possible on HP's and
Sun's for Control-S. Some machines will do it though. The Sun will do
it in the csh and sh (don't know about other shells) but not in vi, the
HP won't do it at all.
rh>
rh>---
rh>John Gordon My incredibly witty saying has been
rh>gordon@osiris.cso.uiuc.edu Politically Corrected into oblivion.
Ronald.
---
__
// Ronald Hello (hello@cs.utwente.nl)
// Department of Computer Science
// University of Twente
// The Netherlands
From lange@obelix.pcs.dec.com (Ralf Lange Digital-PCS GmbH)
Subject: Re: Q: Inputting an Escape Sequence w/VI
Reply-To: lange@obelix.pcs.dec.com (Ralf Lange Digital-PCS GmbH)
Date: Wed, 14 Jul 1993 13:06:55 GMT
go into insert mode and type
^V^[
every time you want to place the escape character
in your text. '^V' means CTRL-V and '^[' is the Escape key.
Ralf
From hansm@wsinti06.info.win.tue.nl (Hans Mulder)
Subject: Re: Q: Inputting an Escape Sequence w/VI
Date: 14 Jul 1993 16:50:33 +0200
In <147620001@capella.cup.hp.com> alicef@capella.cup.hp.com (Alice Farrelly) writes:
>Hi ,
>This is a quick question,
>How do I put escape sequences in a file using vi?
Type a control-V before the escape.
>I want to add the following sequence to highlight some lines.
>ESC&dA ([&dA)
That won't work on most terminals. Most terminals want something
like ESC[7m . If you want to write something that works on many
terminals, you'll have to extract the appropriate escape sequence
from the termcap (or terminfo) database. Or put a _ and a backspace
in front of every highlighted character, and let a program like more
(or ul, or less) figure it out.
To put a backspace in a file using vi, you have to type a control-V
before the backspace.
HansM
From ray@Celestial.COM (Ray Jones)
Subject: Re: Q: Inputting an Escape Sequence w/VI
Date: Wed, 14 Jul 1993 16:27:20 GMT
In <147620001@capella.cup.hp.com> alicef@capella.cup.hp.com (Alice Farrelly) writes:
>Hi ,
>This is a quick question,
>How do I put escape sequences in a file using vi?
>I want to add the following sequence to highlight some lines.
>ESC&dA ([&dA)
This is the vary standard way to include any unprintable character in a
vi file. While in the input mode, enter a Control-V, followed by the
charater you wish to enter. For your example:
Control-V ESC &dA
and it will look like
^[&dA
--
INTERNET: ray@Celestial.COM | The probability of one or more
Ray A. Jones; Celestial Software | spelling errors in this missive
8545 S.E. 68th Street | approaches unity. If this bothers you,
Mercer Island, WA 98040;(206) 236-1676 | run it through your spell checker!
From brandari@anl433.uucp (Paul Brandariz x6546)
Subject: Re: Q: Inputting an Escape Sequence w/VI
Date: Wed, 14 Jul 1993 15:47:36 GMT
Control-V will tell vi to take the next character as is. This is how
you can enter the ESC character.
--
___________________________________________________________________________
Paul R. Brandariz E-mail Internet: paul.brandariz@kla.com
KLA Instruments Corp
P.O. Box 49055 Voice: (408) 456-6546
San Jose, CA 95161-90

34
comp.editors/currfn Normal file
View File

@ -0,0 +1,34 @@
From g88m0396@alpha.ru.ac.za (Jon-Dean Mountjoy)
Subject: Grab current Filename in VI?
Date: Mon, 28 Jun 1993 17:54:07 GMT
Hello
I want to be able to grab the current filename that I am editing,
so that (in a macro), I can say, LaTeX the CURRENT file,
or Ispell the CURRENT file. Something like
map lat :!latex $$
where $$ is the current file that VI is editing.
Thanks
Jon-Dean
--
-------------------------------------------------------------------------------
Jon-Dean Mountjoy csjm@beta.ru.ac.za Rhodes University
The views herein are my own
and not those of the institution
From hrjoist@immd4.informatik.uni-erlangen.de (Holger Joist)
Subject: Re: Grab current Filename in VI?
Date: Mon, 28 Jun 1993 19:01:04 GMT
g88m0396@alpha.ru.ac.za (Jon-Dean Mountjoy) writes:
>I want to be able to grab the current filename that I am editing,
>so that (in a macro), I can say, LaTeX the CURRENT file,
>or Ispell the CURRENT file. Something like
>map lat :!latex $$
>where $$ is the current

914
comp.editors/cutpaste Normal file
View File

@ -0,0 +1,914 @@
From bhoughto@sedona.intel.com (Blair P. Houghton)
Subject: Re: vi (cut and paste)
Date: Mon, 17 Aug 1992 17:04:16 GMT
In article <3815@keele.keele.ac.uk> phd85@seq1.keele.ac.uk (D.H. Holden) writes:
> Does anyone know how you cut a range of text to one
> of the named buffers, where the range does not cover
> an integer number of lines, i.e.,
> How do i cut from here > text text text ..........
> ............... n number of lines .....
> ...... to here < into the named buffer "a for example?
Go to one end of the range and set a mark, then go to the
other end and buffer-yank-to-marked-character, using
double-quote and back-tick; for example, (the mark is "a"
and the buffer is "f", the first letter in the range is the
"b" in "bazz" and the last is the double-quote before the
"b" in "bar"):
/bazz
ma <-- set the mark
/bar
"fy`a <-- yank to marked character
/result
nn"fp
The result is:
The rbazz" and the last is the double-quote before the
"b" in "esult is:
--Blair
"Cake."
From bibb@s912%bnf.com (Ken Bibb)
Subject: Re: vi (cut and paste)
Date: 17 Aug 92 20:01:49 GMT
In <3815@keele.keele.ac.uk> phd85@seq1.keele.ac.uk (D.H. Holden) writes:
> hi,
> Does anyone know how you cut a range of text to one
>
> of the named buffers, where the range does not cover
>
> an integer number of lines, i.e.,
> How do i cut from here > text text text ..........
> ............... n number of lines .....
> ...... to here < into the named buffer "a for example?
> Cheers,
> Dave.
In the following texT:
aaabbbbbb
bbbbbbbbb
bbbbccccc
I'll assume you want to cut the b's out and save them into buffer a.
1) position the cursor at the beginning of the range to be cut (1Gfb will work
in this example).
2) ma (mark the location with marker a)
3) move to the end of the range (Gfc will work in this example)
4) "ad`a will cut the range and put it into buffer a
--
ken@bnf.com jester@crash.cts.com
--
bnf!s912!ken@crash.cts.com "The Fire and the Rose are one"--T.S.Eliot
From sgr@alden.UUCP (Stan Ryckman)
Subject: Re: vi (cut and paste)
Date: 19 Aug 92 16:40:04 GMT
In article <1992Aug17.200149.7817@s912%bnf.com> bibb@s912%bnf.com (Ken Bibb) writes:
>In <3815@keele.keele.ac.uk> phd85@seq1.keele.ac.uk (D.H. Holden) writes:
>> hi,
>> Does anyone know how you cut a range of text to one
>> of the named buffers, where the range does not cover
>> an integer number of lines, i.e.,
>> How do i cut from here > text text text ..........
>> ............... n number of lines .....
>> ...... to here < into the named buffer "a for example?
>> Cheers,
>> Dave.
>In the following texT:
>aaabbbbbb
>bbbbbbbbb
>bbbbccccc
>
>I'll assume you want to cut the b's out and save them into buffer a.
>1) position the cursor at the beginning of the range to be cut (1Gfb will work
> in this example).
>2) ma (mark the location with marker a)
>3) move to the end of the range (Gfc will work in this example)
>4) "ad`a will cut the range and put it into buffer a
NOT!
This grabs all three full lines. (I tried it! Did you?)
Dave presumably wants to have the remaining text be:
aaaccccc
and the buffer to contain:
bbbbbb
bbbbbbbbb
bbbb
"Mark" (the "m" command) only marks the line, NOT the cursor
position within the line.
In this trivial example, the following works:
1) position to the beginning as Ken suggests (1Gfb);
2) type the command "ad/c
which will delete up to the first "c" character, putting the
deletions into the buffer.
However, in the general case this doesn't work; suppose you
want all the b's PLUS the first c to be cut. Then,
"ad2/c
won't work (vi doesn't allow a number before the / command).
Yes, here you could do
"ad/cccc$
and, in most cases, something can be found to work. But to my
mind, there's no way to put the cursor at one arbitrary mid-line
point, type something, then position to another arbitrary mid-line
point, and then delete the in-between-text into a named buffer.
Am cross-posting to comp.editors, since someone there may know
for sure whether there _is_ a way to do this, and if I'm wrong I'd
like to know. But please, _TRY_ it before posting!
Stan.
--
This .signature has expired. Call 1-900-YOU-FOOL to find out why.
Stan Ryckman sgr@alden.UUCP
From asoper@wyvern.twuug.com (Aubrey Soper)
Subject: Re: vi (cut and paste)
Date: 18 Aug 92 20:34:41 GMT
phd85@seq1.keele.ac.uk (D.H. Holden) writes:
> hi,
> Does anyone know how you cut a range of text to one
>
> of the named buffers, where the range does not cover
>
> an integer number of lines, i.e.,
> How do i cut from here > text text text ..........
> ............... n number of lines .....
> ...... to here < into the named buffer "a for example?
> Cheers,
> Dave.
"ad/<
should do it. You can also mark the end and delete to
that mark. I'd recommend that you get a book on vi, such
as UNIX Text Processing by Hayden Books. With only the
UNIX docs, you'll probably wind up hating vi...
aubrey soper
From sgr@alden.UUCP (Stan Ryckman)
Subject: Re: vi (cut and paste)
Date: 19 Aug 92 16:40:04 GMT
In article <1992Aug17.200149.7817@s912%bnf.com> bibb@s912%bnf.com (Ken Bibb) writes:
>In <3815@keele.keele.ac.uk> phd85@seq1.keele.ac.uk (D.H. Holden) writes:
>> hi,
>> Does anyone know how you cut a range of text to one
>> of the named buffers, where the range does not cover
>> an integer number of lines, i.e.,
>> How do i cut from here > text text text ..........
>> ............... n number of lines .....
>> ...... to here < into the named buffer "a for example?
>> Cheers,
>> Dave.
>In the following texT:
>aaabbbbbb
>bbbbbbbbb
>bbbbccccc
>
>I'll assume you want to cut the b's out and save them into buffer a.
>1) position the cursor at the beginning of the range to be cut (1Gfb will work
> in this example).
>2) ma (mark the location with marker a)
>3) move to the end of the range (Gfc will work in this example)
>4) "ad`a will cut the range and put it into buffer a
NOT!
This grabs all three full lines. (I tried it! Did you?)
Dave presumably wants to have the remaining text be:
aaaccccc
and the buffer to contain:
bbbbbb
bbbbbbbbb
bbbb
"Mark" (the "m" command) only marks the line, NOT the cursor
position within the line.
In this trivial example, the following works:
1) position to the beginning as Ken suggests (1Gfb);
2) type the command "ad/c
which will delete up to the first "c" character, putting the
deletions into the buffer.
However, in the general case this doesn't work; suppose you
want all the b's PLUS the first c to be cut. Then,
"ad2/c
won't work (vi doesn't allow a number before the / command).
Yes, here you could do
"ad/cccc$
and, in most cases, something can be found to work. But to my
mind, there's no way to put the cursor at one arbitrary mid-line
point, type something, then position to another arbitrary mid-line
point, and then delete the in-between-text into a named buffer.
Am cross-posting to comp.editors, since someone there may know
for sure whether there _is_ a way to do this, and if I'm wrong I'd
like to know. But please, _TRY_ it before posting!
Stan.
--
This .signature has expired. Call 1-900-YOU-FOOL to find out why.
Stan Ryckman sgr@alden.UUCP
From ianh@nmpd.oz.au (Ian Holland)
Subject: Re: vi (cut and paste)
Reply-To: ianh@nmpd.oz.au
Date: 20 Aug 92 03:04:48 GMT
sgr@alden.UUCP (Stan Ryckman) writes:
>In article <1992Aug17.200149.7817@s912%bnf.com> bibb@s912%bnf.com (Ken Bibb) writes:
>>In <3815@keele.keele.ac.uk> phd85@seq1.keele.ac.uk (D.H. Holden) writes:
>>> hi,
>>> Does anyone know how you cut a range of text to one
>>> of the named buffers, where the range does not cover
>>> an integer number of lines, i.e.,
>>> How do i cut from here > text text text ..........
>>> ............... n number of lines .....
>>> ...... to here < into the named buffer "a for example?
>>> Cheers,
>>> Dave.
>>In the following texT:
>>aaabbbbbb
>>bbbbbbbbb
>>bbbbccccc
>>
>>I'll assume you want to cut the b's out and save them into buffer a.
>>1) position the cursor at the beginning of the range to be cut (1Gfb will work
>> in this example).
>>2) ma (mark the location with marker a)
>>3) move to the end of the range (Gfc will work in this example)
>>4) "ad`a will cut the range and put it into buffer a
>NOT!
I think I have worked out the English translation for this exclamation :-)
>This grabs all three full lines. (I tried it! Did you?)
The given example works with SunOS's vi. Perhaps you have an inferior
version (though this makes me sick in the stomack when I think about it),
or maybe (just maybe) you used ' instead of `.
.
.
.
>"Mark" (the "m" command) only marks the line, NOT the cursor
>position within the line.
This is totally incorrect.
>Am cross-posting to comp.editors, since someone there may know
>for sure whether there _is_ a way to do this, and if I'm wrong I'd
>like to know. But please, _TRY_ it before posting!
Yes I did try the original (valid) suggestion before you read this.
best of luck,
--
- ian...
Ian Holland. NMPD, Telecom. % Ph: +61 7 837 5075 % Explicit hoc totum,
E-Mail: ianh@nmpd.oz.au % Fax: +61 7 837 5253 % Pro Christo da mihi potum!
From smr@hitkw14.pki-nbg.philips.de (S.Riehm)
Subject: Re: vi (cut and paste)
Date: 20 Aug 92 07:03:22 GMT
phd85@seq1.keele.ac.uk (D.H. Holden) writes:
> hi,
> Does anyone know how you cut a range of text to one
>
> of the named buffers, where the range does not cover
>
> an integer number of lines, i.e.,
> How do i cut from here > text text text ..........
> ............... n number of lines .....
> ...... to here < into the named buffer "a for example?
as soon as you mention the word "lines" in vi you get complete lines
only!
However, You can specify a search pattern, or any movement pattern, so
you could move the cursor to the start position, then type;
"ay/< into/^M
using your examply above. This will yank everything up to but not
including the string in the search pattern.
you could also do stupid things like:
"ay120W
which would yank the next 120 blank separated words.
This works for delete, change, >> << etc etc also.
good luck
-----------------------------------------------------------------
Stephen Riehm Configuration Management _-_|\
smr@pki-nbg.philips.de Philips Kommunikations Industrie / \
Work: +49 911 526 2975 Nuernberg, Germany \_.-.*/
Fax: +49 911 526 2095 "I was there, now I am here!" v
"My company speaks another language, I CAN'T speak on it's behalf"
From hansm@cs.kun.nl (Hans Mulder)
Subject: Re: vi (cut and paste)
Date: Thu, 20 Aug 1992 15:35:18 GMT
In <515@alden.UUCP> sgr@alden.UUCP (Stan Ryckman) writes:
>In article <1992Aug17.200149.7817@s912%bnf.com> bibb@s912%bnf.com (Ken Bibb) writes:
>>In the following texT:
>>aaabbbbbb
>>bbbbbbbbb
>>bbbbccccc
>>
>>I'll assume you want to cut the b's out and save them into buffer a.
>>1) position the cursor at the beginning of the range to be cut (1Gfb will work
>> in this example).
>>2) ma (mark the location with marker a)
>>3) move to the end of the range (Gfc will work in this example)
>>4) "ad`a will cut the range and put it into buffer a
>NOT!
>This grabs all three full lines. (I tried it! Did you?)
Yes. It works. What you did was "ad'a which indeed grabs three full lines.
Maybe you have a problem distinguishing quote (') from backquote(`). They're
very similar on some displays.
If you use quote ('), you'll grab whole lines; if you use backquote(`), you'll
only grab the appropriate parts of the first and last lines.
--
Hope this helps
Hans Mulder hansm@cs.kun.nl
From bhoughto@sedona.intel.com (Blair P. Houghton)
Subject: Re: vi (cut and paste)
Date: Thu, 20 Aug 1992 01:35:31 GMT
In article <515@alden.UUCP> sgr@alden.UUCP (Stan Ryckman) writes:
>"Mark" (the "m" command) only marks the line, NOT the cursor
>position within the line.
Just what sort of vi(1) are you using?
The backtick (`) command would be useless unless the mark
(m) command marked the precise location of the cursor, and
both have worked just fine for me on the dozen or so UNIXen
on which I've had the opportunity to run vi(1).
--Blair
"No, I won't make a crude
remark about how silly
this argument would be
in EMACS."
From Tom Christiansen <tchrist@convex.COM>
Subject: Re: vi (cut and paste)
Date: Thu, 20 Aug 1992 18:17:06 GMT
Reply-To: tchrist@convex.COM (Tom Christiansen)
Corp. The opinions expressed are those of the user and
not necessarily those of CONVEX.
>From the keyboard of sgr@alden.UUCP (Stan Ryckman):
:Well, I learned something new about vi. I'll add ` to my list of
:useful but undocumented commands.
The ` is certainly documented!
--tom
--
Tom Christiansen tchrist@convex.com convex!tchrist
Perle, plesaunte to prynces paye/ To clanly clos in golde so clere,
Oute of oryent, I hardyly saye/ Ne proued I neuer her precios pere.
From dawson@intelhf.hf.intel.com (Bryan Dawson)
Subject: Re: vi (cut and paste)
Date: Thu, 20 Aug 92 17:49:52 GMT
sgr@alden.UUCP (Stan Ryckman) writes:
>In article <1992Aug17.200149.7817@s912%bnf.com> bibb@s912%bnf.com (Ken Bibb) writes:
>>In <3815@keele.keele.ac.uk> phd85@seq1.keele.ac.uk (D.H. Holden) writes:
>>In the following texT:
>>aaabbbbbb
>>bbbbbbbbb
>>bbbbccccc
>>
>>I'll assume you want to cut the b's out and save them into buffer a.
>>1) position the cursor at the beginning of the range to be cut (1Gfb will work
>> in this example).
>>2) ma (mark the location with marker a)
>>3) move to the end of the range (Gfc will work in this example)
>>4) "ad`a will cut the range and put it into buffer a
>NOT!
WAY!
Note the subtle distinction between the ' single quote and the ` back quote
which is sometimes difficult to see... VI uses the ` back quote to mean
"treat the marks as character positions rather than line positions".
>This grabs all three full lines. (I tried it! Did you?)
I just did and he probably did also... certainly works fine for me.
>aaaccccc
>and the buffer to contain:
>bbbbbb
>bbbbbbbbb
>bbbb
>"Mark" (the "m" command) only marks the line, NOT the cursor
>position within the line.
As noted above, mark DOES mark the "cursor" (character) position but
the 'standard' access to marks using the ' single quote accesses entire
lines. Use the ` back quote to access character positions...
>for sure whether there _is_ a way to do this, and if I'm wrong I'd
>like to know. But please, _TRY_ it before posting!
>Stan.
>--
>This .signature has expired. Call 1-900-YOU-FOOL to find out why.
> Stan Ryckman sgr@alden.UUCP
_________Thanks and Regards from: _____________________________
>> Bryan_Dawson_at_jfccm1@ccm.hf.intel.com (me @ work)
>> (503) 696-4231 >> dawson@pdaxs.techbook.com (me @ play)
At the bank he was shocked to see such a den of equity.
_______________________________________________________________
From mvp@hsv3.lsil.com (Mike Van Pelt)
Subject: Re: vi (cut and paste)
Date: Fri, 21 Aug 1992 18:37:41 GMT
In article <515@alden.UUCP> sgr@alden.UUCP (Stan Ryckman) writes:
>In article <1992Aug17.200149.7817@s912%bnf.com> bibb@s912%bnf.com (Ken Bibb) writes:
>>In <3815@keele.keele.ac.uk> phd85@seq1.keele.ac.uk (D.H. Holden) writes:
>>> How do i cut from here > text text text ..........
>>> ............... n number of lines .....
>>> ...... to here < into the named buffer "a for example?
>>1) position the cursor at the beginning of the range to be cut (1Gfb will work
>> in this example).
>>2) ma (mark the location with marker a)
>>3) move to the end of the range (Gfc will work in this example)
>>4) "ad`a will cut the range and put it into buffer a
>
>NOT!
>This grabs all three full lines. (I tried it! Did you?)
I just tried it, and it worked for me.
Did you use d`a or d'a? 'a moves to the beginning of the
marked line, `a moves to the marked character.
I'm in vi now, and trying it.
Here's my test case:
------------------------------
cut everything from < to the
corresponding end marker
character > in another line.
------------------------------
OK, copy it, and try it out.
ma and mb are set on the < and > characters.
Then I type `a"a`b and here's the result.
------------------------------
cut everything from > in another line.
------------------------------
The trailing marker character is not cut, so this must
affect your selection of where to set the ending mark.
Here's the contents of "a
------------------------------
< to the
corresponding end marker
character
------------------------------
--
Let's face it, when it comes to utilities, Microsoft has | Mike Van Pelt
performed about as well as a savings and loan. These are | Headland Tech.
the guys, remember, who put BACKUP and RESTORE - not to | mvp@hsv3.lsil.com
mention EDLIN - on your hard disk. - Lincoln Spector +----
From stuart@austin.ibm.com (Stuart R. Yoder)
Subject: Re: vi (cut and paste)
Date: 20 Aug 92 19:50:25 GMT
Reply-To: stuart@piobe.austin.ibm.com
In article <515@alden.UUCP>, sgr@alden.UUCP (Stan Ryckman) writes:
> In article <1992Aug17.200149.7817@s912%bnf.com> bibb@s912%bnf.com (Ken Bibb) writes:
> >In <3815@keele.keele.ac.uk> phd85@seq1.keele.ac.uk (D.H. Holden) writes:
>
> >I'll assume you want to cut the b's out and save them into buffer a.
> >1) position the cursor at the beginning of the range to be cut (1Gfb will work
> > in this example).
> >2) ma (mark the location with marker a)
> >3) move to the end of the range (Gfc will work in this example)
> >4) "ad`a will cut the range and put it into buffer a
>
> NOT!
>
> This grabs all three full lines.
NOT! I just tried it and it works great. I'm running
AIX 3.2. I guess different versions of vi work differently.
>
> Dave presumably wants to have the remaining text be:
> aaaccccc
>
> and the buffer to contain:
> bbbbbb
> bbbbbbbbb
> bbbb
>
> "Mark" (the "m" command) only marks the line, NOT the cursor
> position within the line.
>
Depends on your version of vi.
>
> and, in most cases, something can be found to work. But to my
> mind, there's no way to put the cursor at one arbitrary mid-line
> point, type something, then position to another arbitrary mid-line
> point, and then delete the in-between-text into a named buffer.
Depends on your version of vi.
>
>
> Stan.
> --
> This .signature has expired. Call 1-900-YOU-FOOL to find out why.
> Stan Ryckman sgr@alden.UUCP
--
-Stuart
-----------------------------------------------------------
My opinions are mine and not those of my employer.
-----------------------------------------------------------
From smr@hitkw14.pki-nbg.philips.de (S.Riehm)
Subject: Re: vi (cut and paste)
Date: 25 Aug 92 11:15:30 GMT
sgr@alden.UUCP (Stan Ryckman) writes:
>In article <1992Aug17.200149.7817@s912%bnf.com> bibb@s912%bnf.com (Ken Bibb) writes:
>>In <3815@keele.keele.ac.uk> phd85@seq1.keele.ac.uk (D.H. Holden) writes:
>>> hi,
>>> Does anyone know how you cut a range of text to one
>>> of the named buffers, where the range does not cover
>>> an integer number of lines, i.e.,
>>> How do i cut from here > text text text ..........
>>> ............... n number of lines .....
>>> ...... to here < into the named buffer "a for example?
>>> Cheers,
>>> Dave.
>>In the following text:
>>aaabbbbbb
>>bbbbbbbbb
>>bbbbccccc
>>
>>I'll assume you want to cut the b's out and save them into buffer a.
>>1) position the cursor at the beginning of the range to be cut (1Gfb will work
>> in this example).
>>2) ma (mark the location with marker a)
>>3) move to the end of the range (Gfc will work in this example)
>>4) "ad`a will cut the range and put it into buffer a
>NOT!
>This grabs all three full lines. (I tried it! Did you?)
in a REAL vi, using the grave (`) should work only on character
positions, and more or less ignore lines. Try setting a mark (a) in a line
and then moving somewhere else, then type 'a ( normal single quote ),
you will be put to the start of the line, if this was used with a
delete, it would delete the whole line! If however, you use the
backquote or grave character, ie: `a, this will put you on exactly
the same character that was under the cursor when you created the
mark, this when combined with deletes etc works TO THE CHARACTER, and
not on the whole line! Whether the marked character is included or not
I am unsure, I don't know what the official definition says.
catchya
-----------------------------------------------------------------
Stephen Riehm Configuration Management _-_|\
smr@pki-nbg.philips.de Philips Kommunikations Industrie / \
Work: +49 911 526 2975 Nuernberg, Germany \_.-.*/
Fax: +49 911 526 2095 "I was there, now I am here!" v
"My company speaks another language, I CAN'T speak on it's behalf"
From martelli@cadlab.sublink.org (Alex Martelli)
Subject: Re: vi (cut and paste)
Date: 2 Sep 92 13:40:55 GMT
sgr@alden.UUCP (Stan Ryckman) writes:
:In article <1992Aug17.200149.7817@s912%bnf.com> bibb@s912%bnf.com (Ken Bibb) writes:
:>In <3815@keele.keele.ac.uk> phd85@seq1.keele.ac.uk (D.H. Holden) writes:
:>> hi,
:>> Does anyone know how you cut a range of text to one
:>> of the named buffers, where the range does not cover
:>> an integer number of lines, i.e.,
:>> How do i cut from here > text text text ..........
:>> ............... n number of lines .....
:>> ...... to here < into the named buffer "a for example?
:>> Cheers,
:>> Dave.
:>In the following texT:
:>aaabbbbbb
:>bbbbbbbbb
:>bbbbccccc
:>
:>I'll assume you want to cut the b's out and save them into buffer a.
:>1) position the cursor at the beginning of the range to be cut (1Gfb will work
:> in this example).
:>2) ma (mark the location with marker a)
:>3) move to the end of the range (Gfc will work in this example)
:>4) "ad`a will cut the range and put it into buffer a
:
:NOT!
:
:This grabs all three full lines. (I tried it! Did you?)
You are wrong. Yes, I did try Ken's suggestion, and it works perfectly!
Your mistake is probably that sub 4), where Ken specifies a ` (reverse
quote) you used a ' (quote); THAT would grab the three full lines!
:Dave presumably wants to have the remaining text be:
:aaaccccc
:
:and the buffer to contain:
:bbbbbb
:bbbbbbbbb
:bbbb
Which is EXACTLY what Ken's
From tede@alcor.concordia.ca ( TED EWANCHYNA )
From: tede@alcor.concordia.ca ( TED EWANCHYNA )
Newsgroups: comp.editors
Subject: Re: cut and paste in vi problem
Date: Tue, 14 Dec 1993 19:11:19 GMT
Organization: Concordia University, Montreal, Quebec
Lines: 57
In article <CHDF54.9J@newsflash.concordia.ca> tede@alcor.concordia.ca ( TED EWANCHYNA ) writes:
>I am trying to solve an annoying problem that I have had with vi
>for some time now. This problem occurred "sporadically" but I now
>think I can pinpoint the problem (not the solution).
>
>My goal: delete a block and move it to a new location in the file.
>My method: .,$d, followed by p
>Result: it works..., but if I deleted a line or word (dd, dw respectively)
>before I delete with .,$d, I end up with that buffer, not the 'ex' buffer
>when I try and put (p) the buffer back into the new file position.
>I figure my problem is mixing ex with vi style commands. So I tried
>to use :pu instead of p - lo and behold - same problem.
>
>I may get suggestions to do a cut and paste differently, but I LIKE
>using relative references for deleting, so is there any way to
>find out what/why this is occurring? Maybe I can work arounf this problem.
>I'd also like to know if I can examine the cut buffer. I am using a
>DECStation/Ultrix box. I seem to recall having a similiar problem on a Sun
>though.
It's me again. Thanks to all who posted and e-mailed answers. Since my initial
post I have read some documentation (O'Reilly's Learning the VI Editor,
HP's excellent the Ultimate Guide to VI, various files from one of the
vi archive mirror sites). I have also applied some of the suggestions.
I am happy with how I do moves and copies of text blocks (I like
dG and the p, but what I really like is that the target (G) can be
changed to any target, ie the d<target> method allows me to use
the current position + the <target> to delineate a block to delete
and the target is any line movement command (eg, G, /<pattern, +n, etc
that I already know). Reading the books put together 2 pieces of information
that I already had known but had not thought of.
This leads me t the following 2 points.
1) Why is the Unix documentation on vi SO BAD. Why did I have to read 3rd
party sources to really learn how to use an editor that I have been
using for years. Everyone should really be able to read a good book
like any of the 2 I mentioned above, without going through so much
trouble. It seems I have to learn everything about vi just to answer
anything. Anyone who has not read one of these books does not know vi.
Even if you think you know vi, these books will really bring together
a lot - you'll hear yourself saying "of course, how obvious" and wonder
why after all these years you never did it another (a better) way before.
2) I still don't understand why when I delete a word (dw) then I delete a
block with an ex command (:.d), that when I use the put (p) command
to move (what I think is the last delete) I get the dw buffer back
and not the text from the :.d. I implore anyone to give me an answer
- is this a bug??!! The only bug I read about in vi is the c'd command
when your backreference the d (type md then move past it and issue c'd,
you get a core dump everytime! but only if you use d, nothing else).
Back to my 'bug'... I can't find where the text of the ex delete went.
I look through each numbered buffer, nada, where does this text go?
Who can I write to to establish if this really is a bug or not?
From ray@Celestial.COM (Ray Jones)
From: ray@Celestial.COM (Ray Jones)
Newsgroups: comp.editors
Subject: Re: cut and paste in vi problem
Date: Thu, 16 Dec 1993 17:56:54 GMT
Organization: Celestial Software, Mercer Island, WA
Lines: 68
In <CI1HAv.MIw@newsflash.concordia.ca> tede@alcor.concordia.ca ( TED EWANCHYNA ) writes:
>In article <CHDF54.9J@newsflash.concordia.ca> tede@alcor.concordia.ca ( TED EWANCHYNA ) writes:
>It's me again. Thanks to all who posted and e-mailed answers. Since my initial
>post I have read some documentation (O'Reilly's Learning the VI Editor,
>HP's excellent the Ultimate Guide to VI, various files from one of the
>vi archive mirror sites). I have also applied some of the suggestions.
>I am happy with how I do moves and copies of text blocks (I like
>dG and the p, but what I really like is that the target (G) can be
>changed to any target, ie the d<target> method allows me to use
>the current position + the <target> to delineate a block to delete
>and the target is any line movement command (eg, G, /<pattern, +n, etc
>that I already know). Reading the books put together 2 pieces of information
>that I already had known but had not thought of.
>This leads me t the following 2 points.
>1) Why is the Unix documentation on vi SO BAD. Why did I have to read 3rd
>party sources to really learn how to use an editor that I have been
>using for years. Everyone should really be able to read a good book
>like any of the 2 I mentioned above, without going through so much
>trouble. It seems I have to learn everything about vi just to answer
>anything. Anyone who has not read one of these books does not know vi.
>Even if you think you know vi, these books will really bring together
>a lot - you'll hear yourself saying "of course, how obvious" and wonder
>why after all these years you never did it another (a better) way before.
The editor, vi, is tacked on by Unix os vendors, it is mostly unsupported.
It was written by Bill Joy (VP Sun) while he was at the University of Calif
at Berkeley = public domine. Every vendor twiques it a little here and
there so little bugs or differences get in. No one seems to document it
because "everyone know it" (NOT). This has lead to a cottage industry of
"How to" books on vi.
>2) I still don't understand why when I delete a word (dw) then I delete a
>block with an ex command (:.d), that when I use the put (p) command
>to move (what I think is the last delete) I get the dw buffer back
>and not the text from the :.d. I implore anyone to give me an answer
>- is this a bug??!! The only bug I read about in vi is the c'd command
Don't know where your delete goes, but you might try yanking into a buffer
prior to your delete. This will retain the information in the buffer until
you close vi. The contents can be "put" at any time, even if you go to the
next file.
"a4yy
will yank 4 lines into buffer "a"
You can delete (4dd) if you like or just copy (paste?) those line after the
cursor (anywhere in this file or the "next" file) with
"ap
There are 26 of these buffers (a-z). BTW, if you use
"A4yy
this will append to buffer "a" instead of overwritting the buffer.
>when your backreference the d (type md then move past it and issue c'd,
>you get a core dump everytime! but only if you use d, nothing else).
>Back to my 'bug'... I can't find where the text of the ex delete went.
>I look through each numbered buffer, nada, where does this text go?
>Who can I write to to establish if this really is a bug or not?
It may be on the version on your machine but may not be reproducable on the
next (different version of the os).
--
INTERNET: ray@Celestial.COM | The probability of one or more
Ray A. Jones; Celestial Software | spelling errors in this missive
8545 S.E. 68th Street | approaches unity. If this bothers you,
Mercer Island, WA 98040;(206) 236-1676 | run it through your spell checker!
From afsypng@cmcws75.cmc.aes.doe.ca (Jacques Marcoux)
From: afsypng@cmcws75.cmc.aes.doe.ca (Jacques Marcoux)
Newsgroups: comp.editors
Subject: Re: cut and paste in vi problem
Date: Fri, 17 Dec 1993 11:55:12 GMT
Organization: Centre Meteorologique Canadien
Lines: 14
>In article <CHDF54.9J@newsflash.concordia.ca> tede@alcor.concordia.ca ( TED EWANCHYNA ) writes:
... [stuff deleted]
>2) I still don't understand why when I delete a word (dw) then I delete a
>block with an ex command (:.d), that when I use the put (p) command
>to move (what I think is the last delete) I get the dw buffer back
>and not the text from the :.d. I implore anyone to give me an answer
>- is this a bug??!! The only bug I read about in vi is the c'd command
Seems to vary with the vi incarnation, on HP-UX (p) put the last deleted
block of text, on some other however it seems that there is separate
unnamed buffer for vi and for ex. So if you delete text with :.d you
have to use :pu to put it back.
From syklb@osiris.giss.nasa.gov (Ken Bell)
From: syklb@osiris.giss.nasa.gov (Ken Bell)
Newsgroups: comp.editors
Subject: Re: cut and paste in vi problem
Date: 17 Dec 1993 15:00:35 -0500
Organization: NASA Goddard Institute for Space Studies, NYC
Lines: 17
In article <AFSYPNG.93Dec17065513@cmcws75.cmc.aes.doe.ca>,
Jacques Marcoux <afsypng@cmcws75.cmc.aes.doe.ca> wrote:
>Seems to vary with the vi incarnation, on HP-UX (p) put the last deleted
>block of text, on some other however it seems that there is separate
>unnamed buffer for vi and for ex. So if you delete text with :.d you
>have to use :pu to put it back.
I find that if I delete or yank text via "dd", ":d", "yy", or ":y"
commands, and then issue an "o" or "O", followed by <Esc>, neither
"p" nor ":pu" commands find any text in the buffer. Is this "normal"?
(FWIW, on RS/6000 running AIX 3.2)
--
Ken Bell
syklb@nasagiss.giss.nasa.gov / syklb@nasagiss.bitnet / (212)-678-5545

286
comp.editors/demyst Normal file
View File

@ -0,0 +1,286 @@
From hansm@wsinti04.info.win.tue.nl (Hans Mulder)
Subject: Re: Demystifying vi one step further..
Date: 29 Jun 1993 14:38:43 +0200
In <C9Cnsu.5Do@vti.com> johnw@vti.com (John Wiegley) writes:
>Here's something neat I just learned while playing around
>with vi the other day. Usually when I learn an arcane tool,
>I like to guess the author's motives behind naming all the
>key-combinations (because that helps me remember them).
I'm afraid that for some key-combinations (e.g. control-G),
the motive was mostly that all of the good ones were taken.
>Two of the ones I couldn't figure out in vi were "t" and "f".
> [n] f [character] - jump to the nth occurence of character.
> [n] t [character] - jump to the character JUST BEFORE
> the nth occurence of character.
> [n] F [character] - jump back to the nth occurence of char.
> [n] T [character] - jump back to the character JUST AFTER
> the nth occurence of character.
>Well, the reason for having these commands seemed a little
>obscure, and the reason for their names was even MORE obscure,
>until one day...
> I was editing a ":" delimited database, and realized that
> I could conveniently jump to field "9" by typing "9f:". So
> the "f" stood for "field". Or, if I wanted to delete the
> first four fields on a line, I could type "d4f:".
> And..
> I was hacking around in some files, and got to a line where
> I wanted to delete everything UP TO, BUT NOT INCLUDING some
> character. I then realized that "t" stands for "to". You
> can read "d2tk" as "delete to the 2nd k".
>Using those pneumonics I never forget the pair, and find that
>I use them all the time now..
To save you some wear of the "f" and "t" keys, let me point out
that ";" repeats the most recent "f", "t", "F" or "T", and ","
jumps to the same character in the opposite direction.
I have no idea why ";" and "," were chosen for this function.
HansM
From tbrown@db1 (Terry Brown)
Subject: Re: Demystifying vi one step further..
Date: Tue, 29 Jun 1993 13:50:27 GMT
johnw@vti.com (John Wiegley) writes:
: I was editing a ":" delimited database, and realized that
: I could conveniently jump to field "9" by typing "9f:". So
: the "f" stood for "field". Or, if I wanted to delete the
: first four fields on a line, I could type "d4f:".
:
Funny, I always though 'f' stood for 'find'.
: Using those pneumonics I never forget the pair, and find that
: I use them all the time now..
:
And not that they only work on the current line, they never
take you to another line.
__o
_`\<,_ Terry
(_)/ (_)
From ray@Celestial.COM (Ray Jones)
Subject: Re: Demystifying vi one step further..
Date: Tue, 29 Jun 1993 16:35:26 GMT
In <C9Cnsu.5Do@vti.com> johnw@vti.com (John Wiegley) writes:
[stuff about vi being obscure deleted]
>Well, the reason for having these commands seemed a little
>obscure, and the reason for their names was even MORE obscure,
>until one day...
> I was editing a ":" delimited database, and realized that
> I could conveniently jump to field "9" by typing "9f:". So
> the "f" stood for "field". Or, if I wanted to delete the
> first four fields on a line, I could type "d4f:".
> And..
> I was hacking around in some files, and got to a line where
> I wanted to delete everything UP TO, BUT NOT INCLUDING some
> character. I then realized that "t" stands for "to". You
> can read "d2tk" as "delete to the 2nd k".
>Using those pneumonics I never forget the pair, and find that
>I use them all the time now..
In the classes I teach on vi, I try to point out to the students that almost
all vi commands are pneumonic. I think "f" means "forward", BTW, but
"field" if it helps you remember.
Some other helpful hints: Uppercase keys have either a greater action than
the lowercase key (as in a,A i,I u,U h,H l,L w,W e,E r,R b,B c,C d,D s,S) or
the opposite action ( as in f,F t,T o,O p,P)
--
INTERNET: ray@Celestial.COM Ray A. Jones; Celestial Software
UUCP: ...!thebes!camco!ray 6641 East Mercer Way
uunet!camco!ray Mercer Island, WA 98040; (206) 947-5591
The probability of one or more spelling errors in this missive approaches
From william@festival.ed.ac.uk (William Warburton)
Subject: Re: Demystifying vi one step further..
Date: 30 Jun 93 09:34:32 GMT
Reply-To: W.Warburton@ed.ac.uk
|> In <C9Cnsu.5Do@vti.com> johnw@vti.com (John Wiegley) writes:
|> ...
|> >Using those pneumonics I never forget the pair, and find that
In article <1993Jun29.163526.19829@Celestial.COM>, ray@Celestial.COM (Ray Jones) writes:
|> all vi commands are pneumonic. I think "f" means "forward", BTW, but
Mnemonic. I think pneumonic implies airheaded.
|> The probability of one or more spelling errors in this missive approaches
Your .sig is being stripped to four lines, I think, either that or
it could use a full stop to clarify its rather "zen" ring. :-)
W.
--
| W.Warburton@ed.ac.uk Tune to KBHR, 570 AM!
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
From hansm@wsinti04.info.win.tue.nl (Hans Mulder)
Subject: Re: Demystifying vi one step further..
Date: 30 Jun 1993 16:06:27 +0200
In <1993Jun29.163526.19829@Celestial.COM) ray@Celestial.COM (Ray Jones) writes:
)In <C9Cnsu.5Do@vti.com> johnw@vti.com (John Wiegley) writes:
)[stuff about vi being obscure deleted]
)In the classes I teach on vi, I try to point out to the students that almost
)all vi commands are pneumonic. I think "f" means "forward", BTW, but
)"field" if it helps you remember.
I thought it meant "find", but hey...
)Some other helpful hints: Uppercase keys have either a greater action than
)the lowercase key (as in a,A i,I u,U h,H l,L w,W e,E r,R b,B c,C d,D s,S) or
)the opposite action ( as in f,F t,T o,O p,P)
... or something completely unrelated (as in j,J m,M z,Z)
HansM
P.S. The pairs n,N and x,X are missing from your opposites list.
From Ophof@CS.UWindsor.Ca (F. Scott Ophof)
Subject: Re: Demystifying vi one step further..
Date: 30 Jun 1993 12:47:40 -0500
On 29 Jun 1993 12:38:43 GMT Hans Mulder said:
>In <C9Cnsu.5Do@vti.com> johnw@vti.com (John Wiegley) writes:
> >Here's something neat I just learned while playing around
> >with vi the other day. Usually when I learn an arcane tool,
> >I like to guess the author's motives behind naming all the
> >key-combinations (because that helps me remember them).
>I'm afraid that for some key-combinations (e.g. control-G),
>the motive was mostly that all of the good ones were taken.
And that points out the main problem when linking commands to
key-combinations instead of supplying the commands as easy-to-
remember WORDS which users can then link to any key-combo they
wish, or type as-is on a command-line...
Disallowing a command-line (or some alternative to the default
method of command-invocation) is imho one of the gravest errors
application implementors make most often. And I know only one
editor which allows the user the freedom to (re)define commands
and their invocation-method (plus synonyming). Though I might
change my mind after trying out "ne", advertised recently here
on comp.editors.
Regards.
$$\
From penny@root.co.uk (Penny Gaines)
Subject: Re: Demystifying vi one step further..
Date: Mon, 5 Jul 1993 13:59:19 GMT
In <1993Jul2.210933.17371@ucsu.Colorado.EDU> crosby@ucsu.Colorado.EDU (Matthew Crosby) writes:
>Ok. Why is dd delete line? Wouldn't dl be better? Is it just because dd is
>fast to type? Does anyone know.
>-Matt crosby@cs.colorado.edu
dl will delete to next character left, but most people use its fast form, 'x'.
In commands that process text that character twice acts on the whole line -
hence dd, cc, yy.
In vi you can combine any command that processes text (e.g. c,d,y)
with any command that moves the cursor (e.g. l, M, w).
Once you realise this (i.e. so you can use it without thinking about it), you will
realise one of the reasons why vi is so powerful. For the record, when deleting
the stuff in your posting I used d} and d4L, to delete most of the extraneous stuff.
Penny Gaines
From hansm@wsinti06.info.win.tue.nl (Hans Mulder)
Subject: Re: Demystifying vi one step further..
Date: 6 Jul 1993 21:48:59 +0200
In <C9p2ux.7JA@root.co.uk> penny@root.co.uk (Penny Gaines) writes:
>In <1993Jul2.210933.17371@ucsu.Colorado.EDU> crosby@ucsu.Colorado.EDU (Matthew Crosby) writes:
>>Ok. Why is dd delete line? Wouldn't dl be better? Is it just because dd is
>>fast to type? Does anyone know.
>>-Matt crosby@cs.colorado.edu
>dl will delete to next character left, but most people use its fast form, 'x'.
Actually, 'l' moves the cursor to the right, 'dl' and 'x' delete the
character under the cursor; 'h' move the cursor left, 'dh' and 'X'
delete the character to the left of the cursor.
>In commands that process text that character twice acts on the whole line -
>hence dd, cc, yy.
For consistency, there is a "line" command: '_', e.g. 'd_' deletes the
current line '42y_' yanks 42 lines, etc. "Stuttering" (doubling the
operator character) is more convenient, though.
>In vi you can combine any command that processes text (e.g. c,d,y)
>with any command that moves the cursor (e.g. l, M, w).
>Once you realise this (i.e. so you can use it without thinking about it), you
>will realise one of the reasons why vi is so powerful. For the record, when
>deleting the stuff in your posting I used d} and d4L, to delete most of the
>extraneous stuff.
Plus, if you learn more operators and more movement commands, the number
of useful combinations goes up very quickly.
HansM
From ray@Celestial.COM (Ray Jones)
Subject: Re: Demystifying vi one step further..
Date: Tue, 06 Jul 1993 20:19:27 GMT
In <1993Jul2.210933.17371@ucsu.Colorado.EDU> crosby@ucsu.Colorado.EDU (Matthew Crosby) writes:
>In article <1993Jul01.161714.15055@Celestial.COM> ray@Celestial.COM (Ray Jones) writes:
>>
>...
>>
>Ok. Why is dd delete line? Wouldn't dl be better? Is it just because dd is
>fast to type? Does anyone know.
Could be, however, (another fact about vi) double letter command are used to
indicate whole lines. Examples: d=delete, dd delete line(s), c=chan

262
comp.editors/executing Normal file
View File

@ -0,0 +1,262 @@
From nh@cbnewsg.cb.att.com (nicholas.hounsome)
Subject: Re: UNIX COMMAND IN VI SESSION.
Date: Fri, 2 Oct 1992 07:33:09 GMT
>From article <=1=p9lb@lynx.unm.edu>, by hamjavar@carina.unm.edu (Farid Hamjavar):
>
> Hello : OCT-01-92
>
> VI allows you to execute UNIX commands in a VI session.
> How can I enter AT THE CURSER, the output of the UNIX's "date" command ?
>
:map ^X i^M^[:r!date^MddpkkJJ
This will not work correctly at the end of a line because of the two joins.
or
:map ^X ma:r!date^Mj0d$`apmajdd`a
This uses d$ to delete to the end of the line but not the newline and
uses the little known but useful backquote which puts you at the marked
character position.
There is no way to read in directly at the cursor position because
the read has to be done in ex line editor mode which does not understand
cursor position (or `).
>
>
> ThankS a lot.
> Farid Hamjavar
> hamjavar@carina.unm.edu
Nic Hounsome
From shrchin@csug.cs.reading.ac.uk (Jonathan H. N. Chin)
Subject: Re: UNIX COMMAND IN VI SESSION.
Date: 2 Oct 92 08:29:38 GMT
hamjavar@carina.unm.edu (Farid Hamjavar) asked:
>VI allows you to execute UNIX commands in a VI session.
>How can I enter AT THE CURSER, the output of the UNIX's "date" command ?
If you want the cursor to end up in the same place as it started:
mao^[!!date^M"ad$`aPjdd`a
where ^[ is the ESC key and ^M is the RETURN key. Alternatively to get the
cursor to finish _after_ the inserted text:
i^M^Mx^[k!!date^MkJxJxx
Again ^[ is ESC and ^M is RETURN. The first and last x are not needed but ensure
that no spaces are either added or deleted.
Note that there are numerous other ways to do this operation. If you don't plan
on using the above inside a macro, you can omit the named buffers from the first
example, making it the same number of keystrokes as the second example. Or you can
omit various bits if you don't care where the cursor ends up, etc.
Jonathan
--
Jonathan H N Chin, 8 kyu \ Dept. of Cybernetics, \ "Respondeo, etsi mutabor"
\ University of Reading \
shrchin@uk.ac.rdg.susssys1 \ Box 225, Whiteknights \ < Rosenstock-Huessy >
bq305@cleveland.freenet.edu \ Reading, RG6 2AY, U K \
From rac@sherpa.uucp (Roger Cornelius)
Subject: Re: UNIX COMMAND IN VI SESSION.
Date: Fri, 02 Oct 1992 14:13:43 GMT
In article <=1=p9lb@lynx.unm.edu>, hamjavar@carina.unm.edu (Farid Hamjavar) writes:
>
> Hello : OCT-01-92
>
> VI allows you to execute UNIX commands in a VI session.
> How can I enter AT THE CURSER, the output of the UNIX's "date" command ?
vi has no builtin way to do this.
!!date
will overwrite the contents of the current line, or
:<address>r !date
will insert the date at <address> or after the current line if
<address> is not specified. Otherwise, create a macro to do what
you want.
--
Roger Cornelius sherpa!rac@uunet.uu.net ...!uunet!sherpa!rac
From hansm@cs.kun.nl (Hans Mulder)
Subject: Re: Paragraphs and vi
Date: Mon, 5 Oct 1992 14:29:57 GMT
In <1992Oct4.050951.2469@ils.nwu.edu> eric@ils.nwu.edu (Eric Goldstein) writes:
>In vi, fmt can be invoked for the paragraph in question by
>using the !}fmt command.
>In my case, this just about works (but not quite). The
>paragraph does get formated, but the system then inserts
>a message directly into my text. Using the example I gave
>earlier:
>------------------------------------------------------------------
>stty: TCGETS: Operation not supported on socket
Oh well, at least stty mentions it's name in the message you get.
Biff just says "Where are you?", giving you no clue whatsoever.
This is essentially question 2.7 in the FAQ for comp.unix.questions.
The answer is that it is a problem with your .cshrc file (or equivalent
for whatever shell you use.)
That file contains a line with an stty command, maybe:
stty erase ^H # or whatever
If your shell is a C shell or compatible, change that to read:
if ($?prompt)
stty erase ^H # or whatever
endif
Or, if it's a Bourne shell compatible, make that:
if [ ${PS1+x} = x ]
then stty erase ^H # or whatever
fi
Oh, if there is a line starting with:
set prompt=
or
PS1=
respectively, put that line between the if/endif pair c.q. then/fi
pair as well.
--
Hope this helps,
Hans Mulder hansm@cs.kun.nl
From pckizer@tamsun.tamu.edu (Philip Kizer)
Subject: Re: Piping just *1* line [Was: mapping space bar]
Date: 27 Jan 1993 22:41:14 -0600
Once, djf@bnr.ca wrote:
>BTW:
> - is there a way to pipe just *1* line through a filter? I find things like
> !jsome_command<return>
>always send two lines.
Certainly:
!!some_command<return>
Just like dd, cc, and yy say to delete, change and yank the current line
(respectively), !! says to pipe the current line to the command.
G'day,
philip
From kevinpb@sierra.COM (Kevin P. Brannen)
Subject: Re: more shell command in "vi"
Date: 26 May 93 17:47:20 GMT
Article-I.D.: sierra.1993May26.174720.15762
In article <1993May22.024258.17919@cs.rit.edu>, xxj3910@cs.rit.edu (Xia X Jin) writes:
|> I have the following question: how to you, for example, do the
|> following sorting in vi:
|>
|> 1. given a line, sort all words in that line alphabetically.
|>
Put your cursor on the line you want to change and try:
!!tr " " "\012" | sort | xargs
|> 2. given several lines, sort those lines according to the second
|> word of each line.
|>
Mark one of the lines (with the ma command) and try:
!'a!sort +1 -2
|>
|>
|> Thanks.
Your welcome, try reading up on the ! command.
|>
|> --
|> Steve xxj3910@cs.rit.edu
Bonus info to whomever: I found a new book about vi that's really good, though
somewhat biased towards HP machines: "The Ultimate Guide to the VI and EX Text
Editors", ISBN#0-8053-4460-8
Kevin Brannen
kevinpb@sierra.com
From dyas@ukraine.corp.mot.com (Bob Dyas)
Subject: vi escape filter problems
Reply-To: dyas@ukraine.corp.mot.com
Date: Sun, 11 Jul 1993 22:22:36 GMT
I've been having a problem whenever I use the vi escape filter mechanism. The
following line always ends up in the file I'm editing:
stty: TCGETS: Operation not supported on socket
Anyone out there know what I can do to get rid of this?
I'm running vi from an xterm under OpenWindows.
---
Bob Dyas
dyas@ukraine.corp.mot.com
From wyg9633@uxa.cso.uiuc.edu (Wooed Sun)
Subject: Why this output with ! in vi?
Date: 21 Jul 1993 19:15:08 GMT
Hi,
When I use '!)sort', ':.,30!sort' or a similar kind in vi, I always get
the output that is preceded by '^[P1.yHHHH:FFFFF^[\'
('^[' = Escape; HHHH = machine name; FFFF = file pathname).
What's wrong and how can I avoid this?
BTW, I am editing on an SGI IRIS (4.0).
Thanks in advance.
--
email : w-yang@uiuc.edu (wyg9633@uxa.cso.uiuc.edu)
From hansm@wsinti06.info.win.tue.nl (Hans Mulder)
Subject: Re: Why this output with ! in vi?
Date: 22 Jul 1993 11:57:44 +0200
In <22k4js$2o7@vixen.cso.uiuc.edu> wyg9633@uxa.cso.uiuc.edu (Wooed Sun) writes:
>Hi,
>When I use '!)sort', ':.,30!sort' or a similar kind in vi, I always get
>the output that is preceded by '^[P1.yHHHH:FFFFF^[\'
>('^[' = Escape; HHHH = machine name; FFFF = file pathname).
>What's wrong
In you're .cshrc you're setting

25
comp.editors/history Normal file
View File

@ -0,0 +1,25 @@
From dcd@tc.fluke.COM (David Dyck)
Subject: Origin of % in replacement pattern in vi
Date: 24 Jun 92 19:57:18 GMT
Article-I.D.: tc.1992Jun24.195718.16732
I've been using vi for a long time, but it's been a while
since I've tried the command
:s/foo/%/
Until now this would replace the string foo with the character '%',
but now it appears that % does something similar to the metacharacter ~
in the replacement part of a substitute command.
Earlier vi's did not do this, and the earlier manuals did not mention
this (Although the LATEST manual from Sun that we have (SunOS Release 4.1.2)
has added a sentence about it.
Would someone please explain why vi was changed?
(I have seen mentions about a ucb vs. sysV vi, is this one of the new
features of sysV?)
David Dyck dcd@tc.fluke.COM

132
comp.editors/insert Normal file
View File

@ -0,0 +1,132 @@
From saunders@luther.che.wisc.edu (Brian E. Saunders)
Subject: vi insert question
Date: 28 May 92 16:20:16 GMT
Say I have 1000 lines of text. Before each line, I want to insert a
specific character. How do I do this with 1 command?
Note: each line before the character is inserted does not begin with the
same character, so I can't do a simple substitution command.
--
Brian E. Saunders saunders@luther.che.wisc.edu
From snk@fork.bae.bellcore.com (Samuel N Kamens)
Subject: Re: vi insert question
Date: 28 May 92 17:58:31 GMT
Reply-To: snk@bae.bellcore.com
In article <1992May28.112017.21007@doug.cae.wisc.edu>, saunders@luther.che.wisc.edu (Brian E. Saunders) writes:
> Say I have 1000 lines of text. Before each line, I want to insert a
> specific character. How do I do this with 1 command?
>
> Note: each line before the character is inserted does not begin with the
> same character, so I can't do a simple substitution command.
> --
Try this:
:1,$s/^/c/
This says:
:1,$ (for every line in the file)
s/^/c/ (replace the regular expression ^, which means
"beginning of line", with the character c).
Sam
--
Sam Kamens Bell Communications Research
snk@bae.bellcore.com Phone: (908) 699-7509
444 Hoes Lane Room RRC 1D-210
Piscataway, NJ 08854
From soh@andromeda.trl.OZ.AU (Kam Hung Soh)
Subject: Re: vi insert question
Date: Thu, 28 May 1992 22:02:42 GMT
snk@fork.bae.bellcore.com (Samuel N Kamens) writes:
>In article <1992May28.112017.21007@doug.cae.wisc.edu>, saunders@luther.che.wisc.edu (Brian E. Saunders) writes:
>> Say I have 1000 lines of text. Before each line, I want to insert a
>> specific character. How do I do this with 1 command?
>:1,$s/^/c/
> :1,$ (for every line in the file)
> s/^/c/ (replace the regular expression ^, which means
> "beginning of line", with the character c).
``%'' is the abbreviation for ``1,$'' - the entire buffer. I.e:
:%s/^/c/
This works for vi under SunOS and vim on the Amiga. For more vi
discussion, read comp.editors.
Regards,
Soh, Kam Hung, Network Management Research, | h.soh@trl.oz.au
TRL, POB 249 Clayton, Victoria 3168, Australia | +61 3 253 6638
From buck@pool.info.sunyit.edu (Jesse Buckley)
Subject: Re: vi insert question
Date: Thu, 28 May 1992 19:51:45 GMT
In article <1992May28.112017.21007@doug.cae.wisc.edu> saunders@luther.che.wisc.edu (Brian E. Saunders) writes:
>Say I have 1000 lines of text. Before each line, I want to insert a
>specific character. How do I do this with 1 command?
>
>Note: each line before the character is inserted does not begin with the
>same character, so I can't do a simple substitution command.
Actually you can. Try this...
:1,$ s/^/XXXX/
It works on my system. (ULTRIX 4.2)
--
=) Buck (buck@sunyit.edu)
"I believe in getting into hot water; it keeps you clean."
-- G. K. Chesterton
From esaffle@gmuvax2.gmu.edu (L. Ron Hoover)
Subject: Re: vi insert question
Date: 29 May 92 03:07:13 GMT
In article <1992May28.112017.21007@doug.cae.wisc.edu> saunders@luther.che.wisc.edu (Brian E. Saunders) writes:
>Say I have 1000 lines of text. Before each line, I want to insert a
>specific character. How do I do this with 1 command?
>
>Note: each line before the character is inserted does not begin with the
>same character, so I can't do a simple substitution command.
if EVERY line has to have something inserted before it, meaning at the start
of every line, try this:
:g/^/s//what you want inserted/
type it as show, substituting in the text you want instead of "what you want
inserted", of course.
Ed
From agc@bnr.ca (Alan Carter)
Subject: Re: vi insert question
Date: Fri, 29 May 1992 09:40:48 GMT
In article <1992May28.112017.21007@doug.cae.wisc.edu>, saunders@luther.che.wisc.edu (Brian E. Saunders) writes:
|> Say I have 1000 lines of text. Before each line, I want to insert a
|> specific character. How do I do this with 1 command?
|>
|> Note: each line before the character is inserted does not begin with the
|> same character, so I can't do a simple substitution command

147
comp.editors/macrolimits Normal file
View File

@ -0,0 +1,147 @@
From jdawson@cs.utexas.edu (John Dawson)
Subject: Vi macro limitation
Date: 22 Jun 1992 01:51:21 -0500
NNTP-Posting-Host: langtry.cs.utexas.edu
I am trying to write moderately complicated vi macros and I'm bashing
my head against limitations whose nature I can't figure out. The
specific problem I was trying to solve is to whack some key, have vi
invoke make and send the output to a file, and edit that file; then,
use the normal motion keys/commands to move to a line that looks like
FILENAME:LINENO:blahblah... # format of gcc
and go to line number LINENO in file FILENAME. My original plan was
to move to the start of the line, and insert ":e ". Go to the next
colon, and insert a CR or ESC. Go to the next colon, and insert G.
Now the line should look like
:e FILENAME:LINENOG:blahblah...
Now the part that I can't do: go to the start of the line, and yank
the stuff up to the colon after FILENAME into one buffer, and yank
the "LINENOG" stuff into a second buffer. After this is all done, do
a U command to restore the line, and @-execute the buffers you just
yanked to.
The problem is that whenever I try to do the yanking into a named
buffer, it gives my my favourite error, "Can't yank inside global/
macro". I wasn't able to get it to yank anything at all
without it giving me that error, as I recall, but I tried doing the
"y" indirectly; i.e., I had a macro like
map =y y
and I would just do =y instead of y for the yank, and that pacified
the "Can't yank inside global/macro" message. But I wasn't able to
do this twice in one macro. (I tried many combinations of this
indirection, and they didn't help.)
This is very baffling. Is someone else familiar with this problem?
If you want the macro I was using to generate this error, the yanking
part went something like this: (the insertion part isn't interesting)
map =e 0"eyt:f:l"gyt:
I don't have the original macro for this stuff; I've found a solution
that works using a single replacement to insert all the stuff on the
line, and then the yanking stuff WORKS! Here's that macro (I've taken
control characters and expanded them, sticking carets underneath them
to show where they are):
map g mm:s/^\([^:][^:]*\):\([0-9][0-9]*\)/:e! \1^V^V^V^[:\2G/^M_
^ ^ ^ ^ ^
map _ 0"e=yt:f:l"g=yt:u'm@e@g
map =y y
map =m :w!^M:!make -k >& ERRS^M:e ERRS^M
^ ^ ^
The fact that the same yanking submacro works given a different
insertion technique is a great source of consternation. What is
the rule for when you can and cannot yank? Is there a workaround
for this? [Note: "Use Emacs instead!" is not a valid answer. A
good friend of mine, a self-proclaimed vi expert, gave me that
sage advice, along with a little lecture on how vi is an editor
and is Meant To Edit Text and isn't a kitchen sink like Emacs.
He should be ashamed of himself. Calling himself a vi guru,
indeed.]
I can't help but think that this is possible to work around. After
all, I've seen gurus of ultimate godliness do things like Turing
machines and maze solvers with vi macros.
--
jdawson@cs.utexas.edu (John Dawson)
From jdawson@cs.utexas.edu (John Dawson)
Subject: Vi macro limitation
Date: 22 Jun 1992 01:51:21 -0500
NNTP-Posting-Host: langtry.cs.utexas.edu
I am trying to write moderately complicated vi macros and I'm bashing
my head against limitations whose nature I can't figure out. The
specific problem I was trying to solve is to whack some key, have vi
invoke make and send the output to a file, and edit that file; then,
use the normal motion keys/commands to move to a line that looks like
FILENAME:LINENO:blahblah... # format of gcc
and go to line number LINENO in file FILENAME. My original plan was
to move to the start of the line, and insert ":e ". Go to the next
colon, and insert a CR or ESC. Go to the next colon, and insert G.
Now the line should look like
:e FILENAME:LINENOG:blahblah...
Now the part that I can't do: go to the start of the line, and yank
the stuff up to the colon after FILENAME into one buffer, and yank
the "LINENOG" stuff into a second buffer. After this is all done, do
a U command to restore the line, and @-execute the buffers you just
yanked to.
The problem is that whenever I try to do the yanking into a named
buffer, it gives my my favourite error, "Can't yank inside global/
macro". I wasn't able to get it to yank anything at all
without it giving me that error, as I recall, but I tried doing the
"y" indirectly; i.e., I had a macro like
map =y y
and I would just do =y instead of y for the yank, and that pacified
the "Can't yank inside global/macro" message. But I wasn't able to
do this twice in one macro. (I tried many combinations of this
indirection, and they didn't help.)
This is very baffling. Is someone else familiar with this problem?
If you want the macro I was using to generate this error, the yanking
part went something like this: (the insertion part isn't interesting)
map =e 0"eyt:f:l"gyt:
I don't have the original macro for this stuff; I've found a solution
that works using a single replacement to insert all the stuff on the
line, and then the yanking stuff WORKS! Here's that macro (I've taken
control characters and expanded them, sticking carets underneath them
to show where they are):
map g mm:s/^\([^:][^:]*\):\([0-9][0-9]*\)/:e! \1^V^V^V^[:\2G/^M_
^ ^ ^ ^ ^
map _ 0"e=yt:f:l"g=yt:u'm@e@g
map =y y
map =m :w!^M:!make -k >& ERRS^M:e ERRS^M
^ ^ ^
The fact that the same yanking submacro works given a different
insertion technique is a great source of consternation. What is
the rule for when you can and cannot yank? Is there a workaround
for this? [Note: "Use Emacs instead!" is not a valid answer. A
good friend of mine, a self-proclaimed vi expert, gave me that
sage advice, along with a little lecture on how vi is an editor
and is Meant To Edit Text and isn't a kitchen sink like Emacs.
He should be ashamed of himself. Calling himself a vi guru,
indeed.]
I can't help but think that this is possible to work around. After
all, I've seen gurus of ultimate godliness do things like Turing
machines and maze s

157
comp.editors/mapping Normal file
View File

@ -0,0 +1,157 @@
From saunders@luther.che.wisc.edu (Brian E. Saunders)
Subject: VI Mapping Help
Date: 11 Sep 92 18:24:32 CDT
I am using remapping commands to do some common tasks in vi in a smaller
amount of time. If I place the map commands in the .exrc file, or the
.login file, these keyboard remappings work when I edit a file in my home
directory, but somehow they don't show up if I'm working in any
subdirectory. Can any of you gurus tell me why this is happenning? My
setting commands in the .exrc file and .login file (e.g. wrapmargin = n)
translate to the subdirectories, so this is very confusing behavior.
--
Brian E. Saunders saunders@luther.che.wisc.edu
From marak@alcor.concordia.ca ( Mike Marak)
Subject: Re: VI Mapping Help
Date: Sat, 12 Sep 1992 04:36:50 GMT
In article <1992Sep11.182433.25903@doug.cae.wisc.edu> saunders@luther.che.wisc.edu (Brian E. Saunders) writes:
>I am using remapping commands to do some common tasks in vi in a smaller
>amount of time. If I place the map commands in the .exrc file, or the
>.login file, these keyboard remappings work when I edit a file in my home
>directory, but somehow they don't show up if I'm working in any
One of the guys in the lab here showed us how to do this. Try this in your
.login:
setenv EXINIT 'set wm=o [any other options] | source ~/.exrc'
This works for ULTRIX (csh), abd should work for other flavors of unix.
Hope this helps
Mike
******************************************************************
* Mike Marak * mike@emc2.concordia.ca * *
* Lab Manager * (514)848-3118 * SPACE *
* EMC Lab * Room CC-109 * FOR *
* Loyola Campus * 7141 Sherbrooke St. W. * RENT *
* Concordia University * Montreal, Canada * *
******************************************************************
From tgtcmv@rwa.urc.tue.nl (Martien Verbruggen)
Subject: Re: VI Mapping Help
Date: 14 Sep 92 08:16:30 GMT
Reply-To: tgtcmv@urc.tue.nl
saunders@luther.che.wisc.edu (Brian E. Saunders) writes:
>I am using remapping commands to do some common tasks in vi in a smaller
>amount of time. If I place the map commands in the .exrc file, or the
>.login file, these keyboard remappings work when I edit a file in my home
>directory, but somehow they don't show up if I'm working in any
>subdirectory. Can any of you gurus tell me why this is happenning? My
>setting commands in the .exrc file and .login file (e.g. wrapmargin = n)
>translate to the subdirectories, so this is very confusing behavior.
>--
>Brian E. Saunders saunders@luther.che.wisc.edu
Normally vi looks for a .exrc in the current directory first, then, if it
doesn't find one, in the directory that is contained by the environment
variable HOME (your home-directory), and then executes.
When you set the EXINIT variable, it will always execute the contents of this,
then look for a .exrc in the current dir, but it doesn't look in your home
directory anymore. (at least the vi versions I worked with didn't).
It took me a very long time to figure this out. Nowadays I don't set EXINIT,
but only keep a .exrc in my home and every other directory where it has to be
different (fortran, c, and so on).
This means that vi always uses the .exrc in my home, except when the current
directory contains one.
Hope this helps.
--
Martien Verbruggen (tgtcmv@chem.tue.nl) |
| If two wrongs don't make a right,
Eindhoven University of technology | try three.
Department of Chemical Engineering |
From DSTEIS01@ulkyvm.louisville.edu (Donald S. Teiser)
Subject: map in .exrc versus via :map in vi itself
Date: Fri, 9 Jul 1993 14:32:30 GMT
I have a question that is probably yet another vi FAQ:
When I do the following in vi, it works for mapping "]" to "^D"
:map ] ^V^D
However, when I add the following line to my .exrc file, I end up with
the infamous "RHS missing" error when I :so .exrc
map ] ^V^D
I do not have this problem when mapping "[" to "^U". Any suggestions?
*********************************************************************
** Donald S. Teiser voice: (502) 588-7994 *
** Tech Support for VMS & Ultrix fax: (502) 588-8896 *
** University of Louisville Louisville, KY 40292 *
** dsteis01@ulkyvm.louisville.edu *
*********************************************************************
From Lowe@Fwva.Saic.Com
Subject: Vi mapping
Date: Wed, 21 Jul 1993 14:25:05 GMT
Hi all. I have a problem. I created the following map in vi:
x j 4dd h dd k P h x d2w x J h r <tab>. I mapped these to g.
When I invoke g, however, it chokes. Any ideas why? Thanks for any
and all help.
grant
From hrjoist@immd4.informatik.uni-erlangen.de (Holger Joist)
Subject: Re: Vi mapping
Date: Wed, 21 Jul 1993 15:21:21 GMT
Lowe@Fwva.Saic.Com writes:
>Hi all. I have a problem. I created the following map in vi:
>x j 4dd h dd k P h x d2w x J h r <tab>. I mapped these to g.
>When I invoke g, however, it chokes. Any ideas why? Thanks for any
>and all help.
After '4dd' the cursor is at the beginning of the line, so 'h' doesn't work.
Did you check the above sequence without mapping?
Bye,
Holger
---
Snail: Holger Joist, Neue Strasse 29, 8520 Erlangen, Germany
Email: hrjoist@immd4.informatik.uni-erlangen.de
From DSTEIS01@ulkyvm.louisville.edu (Donald S. Teiser)
Subject: Re: map in .exrc versus via :map in vi itself
Date: Fri, 9 Jul 1993 20:05:12 GMT
Oh, now I see what is happening. The ^D is being interpreted as an EndOfFile
mark for the .exrc file. Any workarounds possible folks?
*********************************************************************
** Donald S. Teiser voice: (502) 588-7994 *
** Tech Support for VMS & Ultrix fax: (502) 588-8896 *
** University of Louisville Louisville, KY 40292 *
** dsteis01@ulkyvm.louisville.edu *
**********************************************************

277
comp.editors/mapspace Normal file
View File

@ -0,0 +1,277 @@
From buboo@alf.uib.no (Ove Ruben R Olsen)
Subject: Re: mapping space bar
Date: Tue, 26 Jan 93 07:35:56 GMT
Michael Doob writes:
>Is it possible to use the map command to remap the space bar? If so, what's
>the right syntax. Things like ^V<space> won't do the job.
Yes it will, just use more ^V's.
Type this: :map ^V^V^V ^V^F
See this: :map ^V ^F
[NOTE: This is untested, but it seems to work]
You may or may not have troubble with the ~ command.
\Ruben.
--
Ove Ruben R Olsen a Gnarfer and VI user. EMAIL: ruben@uib.no.
Maintaining the EX/VI-archive and a couple of the Comp.Editors FAQs.
People that are ignorant tend to live a frustrated life, at least when
it comes to editing - But I do belive this is a general rule in life
From hansm@cs.kun.nl (Hans Mulder)
Subject: Re: mapping space bar
Date: Tue, 26 Jan 1993 10:47:24 GMT
In <C1F8AD.HF9@ccu.umanitoba.ca> mdoob@ccu.umanitoba.ca (Michael Doob) writes:
>Is it possible to use the map command to remap the space bar? If so, what's
>the right syntax. Things like ^V<space> won't do the job.
In the version I use, SVR3.1, it is possible, and takes *two* ^Vs.
Unfortunately, a number of other command is implemented as if they
were mapped to a combination using space, e.g. `s' is mapped to `c '.
Mapping the space bar messes up `s' and other commands.
It would have been nice if the author of vi had used `l' instead.
It would have been even nicer if user-level maps didn't disturb the
builtin ones, of course.
While we're at it, two years ago Chris Torek posted an article in this
group in which he mentioned that one should not map any of "ailru\_ $".
I can understand most of these, but I have two questions:
(1) What does `\' do?
(2) Which command do I mess up when I map `u'?
--
HansM
From alien@boi.hp.com (Tom von Alten)
Subject: Re: mapping space bar
Date: Tue, 26 Jan 1993 18:58:50 GMT
Hans Mulder (hansm@cs.kun.nl) wrote:
: (1) What does `\' do?
Escapes the following character... from what, and under what circumstances
escapes me (ouch! :-) at the moment.
: (2) Which command do I mess up when I map `u'?
UNDO! UNDO! UNDO!
_____________
Tom von Alten email: alien@boi.hp.com
Hewlett-Packard Disk Memory Division
From dattier@orac.holonet.net (DWT)
Subject: Re: mapping space bar
Date: Thu, 28 Jan 1993 04:30:13 GMT
In article <1993Jan27.214031.3457@bcars6a8.bnr.ca> djf@bnr.ca asks, among
other things to which I have no answers, this one question to which I do:
>BTW:
> - is there a way to pipe just *1* line through a filter? I find things like
>!jsome_command<return>
>always send two lines.
!!command or
!_command or
:.!command
>Also, is there an easy way to have *add* filtered
>output rather than have it replace the input?
Hmm. One could always duplicate the text to be filtered and then filter only
the second copy of it. Say it's a single line: yyp to duplicate it; the
cursor will then be on the lower of the two identical lines, so !!command to
filter it, leaving theFrom rouben@math9.math.umbc.edu (Rouben Rostamian)
Subject: Re: Can I map spacebar in vi?
Date: 9 May 92 00:23:58 GMT
In article <1992May8.142618@bwdla30.bnr.ca> djf@bnr.ca writes:
>Title pretty well sums it up. I would like space to scroll forward a
>screen, like in more (or less), since I can just as easily move forward
>a character using 'l'.
>
>I've tried ^V and \, no luck. Any suggestions?
The following works in ultrix's vi:
:map ^V ^V^F
^
|____ more that one space here
--
@map vi.tab2space
From filbo@deeptht.santa-cruz.ca.us (Bela Lubkin)
Subject: Re: want spaces not tab chars in vi
Date: 10 May 92 20:06:13 GMT
Nick Hounsome wrote:
>From article <1992May7.025815.529@tamsun.tamu.edu>, by dlb5404@tamsun.tamu.edu (Daryl Biberdorf):
>> When I use vi on a Sun 4 under SunOs (er, Solaris, whatever) 4.x with
>> autoindent ON, the editor seems to use tabs to get the cursor under
>> the first character of the previous line. Well, this is fine if I'm
>> the only one who edits the file, but my Emacs-using partner is going
>> nuts because code that I've edited looks positively screwy on her
>> display.
>>
>> Is there any way to make vi use spaces instead of tab characters when
>> it is using autoindent? I can't find it in the manual.
>Don't give in to her!!
>
>If everyone sticks to the normal convention of all terminals that I know of,
>i.e. tab stops every eight spaces then there is never any conflict.
>Some people feel the need get their editor to treat tabs as smaller for
>display purposes because their editors are not as good as vi (in vi you
>can set shiftwidth and it will use the minimum number of spaces and tabs
>t indent to where you want to be.
My, that was certainly a useful answer.
I have the same question as the original poster, and I'd appreciate an
answer, not an attack. In my case, the text being edited is often a
mail message or news article which will likely be replied to by people
who use the "> "-in-left-column quoting convention. Text which contains
tabs does not indent well by this convention, whether or not everyone
"sticks to the normal convention" of 8-position tab stops.
I'm in the habit of piping things through a tab remover before sending
mail, but it's a habit I'd rather lose.
However, and this is more directed at the original poster: I checked
the vi source myself. It does this in function genindent(). The
algorithm is, insert tabs, each one generating <tabstop> amount of
whitespace, until one of those would be too much. Then generate
spaces.
Therefore, if you :set tabstop=1000, you'll generate spaces when you
autoindent. However, if you manually enter a tab, or edit a file
containing tabs, it'll try to display them as 1000 blank spaces each!)
You could undoubtably modify one of the vi clones not to do this your
way, if it doesn't already.
Bela Lubkin * * // filbo@deeptht.santa-cruz.ca.us ZURC ATNAS morf EVIL!
@ * * // belal@sco.com uunet!sco!belal uunet!sco!deeptht!filbo
R Pentomino * \X/ Filbo @ Pyrzqxgl +1 408-476-4633 and XBBS +1 408-476-4945
From hansm@cs.kun.nl (Hans Mulder)
Subject: Re: Can I map spacebar in vi?
Date: Mon, 11 May 1992 10:20:11 GMT
In <1992May8.142618@bwdla30.bnr.ca> djf@bwdla30.bnr.ca (Duane Fowler) writes:
>Title pretty well sums it up. I would like space to scroll forward a
>screen, like in more (or less), since I can just as easily move forward
>a character using 'l'.
>I've tried ^V and \, no luck. Any suggestions?
Try harder, i.e. using more ^V. If you type
:map ^V^V^V ^V^F
is should echo as
:map ^V ^F
and that should do the trick.
Unfortunately, doing this screws up the ~ command.
--
Hope this helps,
Hans Mulder hansm@cs.kun.nl
@map vi.tab2space
From warnold@nomad.urich.edu (William W. Arnold)
Subject: Re: want spaces not tab chars in vi
Date: 11 May 92 14:27:28 GMT
In <236.filbo@deeptht.santa-cruz.ca.us> filbo@deeptht.santa-cruz.ca.us (Bela Lubkin) writes:
>Nick Hounsome wrote:
>>From article <1992May7.025815.529@tamsun.tamu.edu>, by dlb5404@tamsun.tamu.edu (Daryl Biberdorf):
>>> Is there any way to make vi use spaces instead of tab characters when
>>> it is using autoindent? I can't find it in the manual.
[stuff removed]
>Therefore, if you :set tabstop=1000, you'll generate spaces when you
>autoindent. However, if you manually enter a tab, or edit a file
>containing tabs, it'll try to display them as 1000 blank spaces each!)
This is about what I do, with one slight addition:
:map! ^I ^T
those should be actual control characters, with ^V's as needed.
this way, a tab is treated as an indent. Works well.
of course, you still have to untabify files that other people have worked on,
:map ^I 1G!Gexpand^M
in command mode, tab untabs the file.
--
-billy- has8wwa@cabell.vcu.edu warnold@nomad.urich.edu
From lwv26@cas.org (Larry W. Virden)
Subject: Re: Can I map spacebar in vi?
Reply-To: lvirden@cas.org (Larry W. Virden)
Date: Tue, 12 May 1992 16:45:42 GMT
In article <1992May9.002358.23515@umbc3.umbc.edu> rouben@math9.math.umbc.edu (Rouben Rostamian) writes:
:In article <1992May8.142618@bwdla30.bnr.ca> djf@bnr.ca writes:
:>Title pretty well sums it up. I would like space to scroll forward a
:>screen, like in more (or less), since I can just as easily move forward
:>a character using 'l'.
:>
:>I've tried ^V and \, no luck. Any suggestions?
:
:The following works in ultrix's vi:
:
::map ^V ^V^F
:
: ^
: |____ more that one space here
:
:--
Note that using Sun's terminfo based vi, I had to provide TWO ^V characters
before the first of the two blanks. If I just put ^V and one space, then
that turned into another of the blanks between map and the ^V^F.
--
Larry W. Virden UUCP: osu-cis!chemabs!lvirden
Same Mbox: BITNET: lvirden@cas INET: lvirden@cas.org
Personal: 674 Falls Place, Reynoldsburg,OH 43068-1614
America Online: lvirden
From djf@bwdla30.bnr.ca (Duane Fowler)
Subject: Can I map spacebar in vi? Result.
Reply-To: djf@bnr.ca
Date: Thu, 14 May 1992 19:47:22 GMT
Thanks to everyone who replied, email or otherwise. The concensus (100%
in fact) has been desc

125
comp.editors/maptab Normal file
View File

@ -0,0 +1,125 @@
From emm@daneel.rdt.monash.edu.au (Wendigo)
Subject: How to map! the tab character in VI
Date: 1 Jun 92 06:52:12 GMT
How would one map the tab character in vi using the ":map!" command?
Thanx
--
Wendigo [ Occasionally thought of as |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
emm@daneel.rdt.monash.edu.au ] | "This isn't science fiction,
{ Sometimes answers to Evan McLean } | this is StarTrek!"
(Now employed, no thanks to the government)| -- Shelia Willis
From sti@cs.hut.fi (Sami-Jaakko Tikka)
Subject: Re: Mapping <tab> in Vi
Reply-To: Sami.Tikka@hut.fi
Date: Wed, 3 Jun 1992 08:27:52 GMT
In article <1992Jun2.113530.19567@sci.kun.nl> hansm@cs.kun.nl (Hans Mulder) writes:
> you might want to look at the possibility of map!ping <tab> to <control-V>
> and setting shiftwidth to your preferred indent.
I believe the button producing right mix of tabs and spaces is
<control-T> not <control-V> as you said. But that was probably a
typo...
--
Sami.Tikka@hut.fi $@%5%_%F%#%C%+(J "LiveFrom jutta@opal.cs.tu-berlin.de (Jutta Degner)
Subject: Re: Mapping <tab> in Vi
Date: Fri, 29 May 1992 21:47:05 GMT
brecht@white.toronto.edu (Tim Brecht) writes:
> Can anyone tell me how to [..] map! <tab> <number of blank characters>
Some characters are special to vi and must be quoted. To quote, prefix
with <CTRL>V (^V in short). If that doesn't work -- this is the case for
both tab and space -- double the ^V.
you type: map! ^V^V<tab> ^V^V<space>^V^V<space>^V^V<space>
you see: map! ^V<tab> ^V<space>^V<space>^V<space>
Maybe you wont be happy with this, though. To correctly expand tabs,
they must be replaced by tabstop - index % tabstop blanks; and although
it may be possible to painstakingly implement this function in vi, it's
just _so_ much easier to simply call
:%!expand
and leave the work to a tool that was written to do it.
--Jutta
From buboo@alf.uib.no (Ove Ruben R Olsen)
Subject: Re: Mapping <tab> in Vi
Date: Fri, 29 May 92 22:21:13 GMT
Tim Brecht writes:
>This has likely been discussed before but ...
Yes, around october last year and february and march this year :-)
>
>Can anyone tell me how to map the <tab> key to output
>some number of blank characters instead ?
>
>Note that changing tabstop isn't sufficient.
>I want to be able to create a file that does not contain
>any tab characters even though I use the tab key when
>creating the file. It seems to be mainly a problem of
>how to escape the blank characters (and possibly the tab).
>
>map! <tab> <number of blank characters>
You should perhaps have consulted the VI archive (If you read the FAQ
this is known).
Also stay tuned for the next 96 hours to see the FAQ for June :-)
>From one of the INDEX files at the VI/EX archives around the world:
ced.tips.1.Z Comp.Editors tips collection. October 91 issue.
ced.tips.5.Z Comp.Editors tips collection. February 92 issue.
ced.tips.6.Z Comp.Editors tips collection. March 92 issue.
This threee files will deal with the TAB/SPC's in greater length.
The VI/EX archives can be found at:
Europe:
Main site: alf.uib.no (129.177.30.3)
Filearea: pub/lpf/misc
Peak hours: 07.00 am GMT to 03.00 pm GMT
Japan:
Mirror site: utsun.s.u-tokyo.ac.jp (133.11.11.11)
Filearea: misc/vi
Peak hours: 01.00 am GMT to 09.00 am GMT
USA, Canada and Mexico:
Mirror site: cs.uwp.edu (131.210.1.4)
Filearea: /pub/vi
Peak hours: None.
Australia, NZ and the rest Down Under:
Main site: monu6.cc.monash.edu.au (130.194.1.106)
Filearea: /pub/Vi
Peak hours: Not relevent
For more information about the files at the archives and the archives
itself, please read one of the FAQ for Comp.Editors.
If you are in a hurry you may fetch the INDEX file.
If you need more information, you are welcome to mail Ove.R.Olsen@uib.no.
\Ruben.
--
Ove Ruben R Olsen, Professional VI user. EMAIL: Ove.R.Olsen@ubb.uib.no
Maintaining the Largest VI/EX-STUFF Archive in the WORLD (alf.uib.no) and
the Comp.Editors FAQ file. If yo

980
comp.editors/misc Normal file
View File

@ -0,0 +1,980 @@
From spencer@lit.Princeton.EDU (S. Spencer Sun)
Subject: Re: A program to /* comment out */ automaticaly
Date: 22 Oct 92 03:50:26 GMT
Reply-To: spencer@phoenix.princeton.edu (S. Spencer Sun)
This doesn't strike me as being a shell question so I've crossposted to
c.u.misc and directed followups there.
In article <guy.719701506@tdsb-s>, guy@mais.hydro.qc.ca (Guy Harel) writes:
>I was always bothered by the tedious task of placing /*`s and */`s
>around lines of code, and always wondered why on earth haven`t such a
>facility ever been provided (maybe EMACS does this , I`m not sure).
>
>[other comments removed]
>
>#!/bin/csh
>
>exec awk '{ print "/* " $0 " */" }'
Why start another process?
Since you say you're using vi:
1. Move to start of block you want to comment out
2. Type ma (set mark a)
3. Move to end of block you want to comment out
4. issue
:'a,.s/^\(.*\)$/\/\* \1 \*\//
Voila. If you just want to do one line, just do step 4 and leave out
the 'a,. part. (Yes, I've tried this out just to be sure, but I may have
made a typo. If it doesn't work, someone will no doubt correct the typo)
Don't want to memorize this, or don't want to learn what's really going on
here so you can generalize to other useful things? Type it once and put
it in your .exrc.
map <keystroke> <sequence>
This line in $HOME/.exrc will replace <keystroke> with whatever key (if
you want, say, ^A, you have to hit ^V^A to insert the actual control
character) and <sequence> with the nasty-looking stuff above.
All of this assumes you WANT to comment out a large block this way. Why
not just do this? Guess it's a matter of preference.
/*
this is
some code
that I
want
commented
out
*/
much easier to un-comment later, too.
-----
sss/PU'94 Dept of CS (spencer@phoenix.princeton.edu)/JvNCnet (spencer@jvnc.net)
"I once believed in causes too / I had my pointless point of view / And life
went on no matter who was wrong or right..." [Billy Joel, "Angry Young Man"]
From bill@bilver.uucp (Bill Vermillion)
Subject: Re: A program to /* comment out */ automaticaly
Date: Thu, 22 Oct 1992 21:11:16 GMT
In article <1992Oct22.035026.25734@Princeton.EDU> spencer@phoenix.princeton.edu (S. Spencer Sun) writes:
>This doesn't strike me as being a shell question so I've crossposted to
>c.u.misc and directed followups there.
>In article <guy.719701506@tdsb-s>, guy@mais.hydro.qc.ca (Guy Harel) writes:
>>I was always bothered by the tedious task of placing /*`s and */`s
>>around lines of code, and always wondered why on earth haven`t such a
>>facility ever been provided (maybe EMACS does this , I`m not sure).
>>[other comments removed]
>>#!/bin/csh
D>>
>>exec awk '{ print "/* " $0 " */" }'
>Why start another process?
>Since you say you're using vi:
>1. Move to start of block you want to comment out
>2. Type ma (set mark a)
>3. Move to end of block you want to comment out
>4. issue
> :'a,.s/^\(.*\)$/\/\* \1 \*\//
>Don't want to memorize this, or don't want to learn what's really going on
>here so you can generalize to other useful things? Type it once and put
>it in your .exrc.
>map <keystroke> <sequence>
>This line in $HOME/.exrc will replace <keystroke> with whatever key (if
>you want, say, ^A, you have to hit ^V^A to insert the actual control
>character) and <sequence> with the nasty-looking stuff above.
Gee - this one looks easier to type. ;-)
map ^X ^i/* ^[A */^[^
And to comment out a line just to
/* to anywhere in that line and type control x */
just like that!
--
Bill Vermillion - bill@bilver.oau.org bill.vermillion@oau.org
- bill@bilver.uucp
- ..!{peora|ge-dab|tous|tarpit}!bilver!bill
From martelli@cadlab.sublink.org (Alex Martelli)
Subject: Re: VI??? GROSS!
Date: 17 Nov 92 08:21:34 GMT
wolff@inf.fu-berlin.de (Thomas Wolff) writes:
:Most repliers to my posting seem to be that well accustomed to the fact
:that vi is a line editor that they didn't see my point when I wrote
:"arbitrary (!) block of text" (well, maybe "block" was misleading). This
:is not a block of lines (which is the unit of most vi operations) and
:since I referred to "elementary text editing tasks" I didn't mean columns
:either. Suppose I have the lines
: word1 word2 word1
: word3 word4 word3
:and I need the text from "word2 " up to "word4" (assume it's a sentence)
:to be copied or moved elsewhere.If an editor cannot do this with a
:simple command sequence (and without the search trick burdening me with
:the task of counting the occurences of the word following my sentence
:within my sentence, if it can be done that way at all), I just do not
:call it a text editor.
You don't seem to be READING the responses to your post!
1. Place the cursor on the leading "w" of "word2".
(by any means whatsoever).
2. Press: ma
You have thus placed the marker named a on that point.
3. Place the cursor on the final "4" of "word4".
(again, by any means whatsoever).
4. Press: mz
You have thus placed the marker named z on that point.
(note that you have 26 marks at your disposal, named a to z).
5. Press: `a
You will move to the EXACT point of mark a, the leading w of "word2".
Note that this is a BACKquote, also known as GRAVE ACCENT, *NOT* an
apostrophe. The apostrophe would use the mark for line-oriented
operation; the backquote uses it for character-stream operation.
If you don't like this key assignment place a "map ' `" in your
.exrc, and the apostrophe will start working in charstream too.
6. To COPY, press: "ay`z
You have thus yanked the EXACT block of text you're interested in,
into named-buffer a. Note that a BACKQUOTE is needed here, too,
before the z, unless you've mapped things to work differently.
(You have 26 named buffers at your disposal, named a to z).
(If you *already* had text inside named-buffer a, and you wanted
to APPEND these words to that, you could do this by pressing:
"Ay`z - the uppercasing of the buffer name is the trick. By using
the buffername in lowercase, the previous contents of the buffer
are, instead, replaced).
6bis. Or, to MOVE, press: "ad`z
You have thus *deleted* the exact block of text into the named buffer.
7. Now place the cursor wherever you wanted to place the text.
(yet again, by any means whatsoever).
8. Press: "ap
You have put named-buffer a's contents right after the cursorpoint.
Or, Press: "aP to put the same contents right BEFORE the cursorpoint.
Note that in either case the contents go within the textstream at
the cursorpoint, as they have been yanked or deleted as textstream,
not as whole lines.
I don't claim this process is perfect. No immediate visual feedback
is available of where marks are, or what you have yanked. The use
of both lower and upper case for commands, which are not echoed, is
at first confusing, although the mnemonic relationships make it
rather commodious to use after a while (p-ut after, P-ut before;
"a to overwrite buffer a, "A to append to it; and so on).
I *DO* claim that you have flamed the vi editor, and by implication
us, its users, WITHOUT having taken the trouble to learn it AT ALL!
Such characterstream operation, and the backquote movement-command
in particular, are not some sort of "exoterica", but, rather quite
fundamental usage modes of this program!
--
Email: martelli@cadlab.sublink.org Phone: ++39 (51) 6130360
CAD.LAB s.p.a., v. Ronzani 7/29, Casalecchio, Italia Fax: ++39 (51) 6130294
From jxh@math.ksu.edu (James C. Hu)
Subject: Re: Centering lines in vi
Date: 28 Jan 1993 16:43:08 -0600
pietro@nova.bellcore.com (Pietro Manzoni) writes:
>Hi,
>is there anybody who knows whether there is a :map command to center a
>single line in VI?
There is probably already a package that does this, but I'd put this in
as an example on how to build useful simple filters for vi. At the end
of this post is a simple program that centers text. Compile it and
install it in ~/bin/center, or whatever.
Then, make the following map:
:map == !!center^M
(the ^M represents the result of hitting CTRL-V followed by CTRL-M)
Presto, you have a pseudo center "operator". Now you can do a == to
center a single line, or a 5== to center the next 5 lines.
Enjoy.
/* File: center.c
* Creator: James C. Hu (sirius@matt.ksu.ksu.edu)
*
* Description:
* Centers lines of input.
*
* Caveats are that lines cannot be longer than the specified
* centering line length, if they are, then they may be truncated,
* and that the default centering line length is 72.
*
* Copyright:
* This program is placed into the public doman.
*
* Date Started: Thu Jan 28 15:33:44 CST 1993
*
* Change Log:
*/
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
static int length = 72;
static char *buf;
static char format[10]; /* should be enough */
int main(int argc, char *argv[])
{
int i,n,buflen;
char *p;
switch(argc) {
case 2:
length = atoi(argv[1]);
if (length == 0) length = 72;
case 1:
break;
default:
fprintf(stderr, "usage: center [width]");
exit(1);
}
buf = malloc((length + 2) * sizeof(char));
while (fgets(buf, length+2, stdin) != NULL) {
if ((p = strrchr(buf, '\n')) != NULL) *p = '\0';
while (isspace(*buf)) buf++;
buflen = strlen(buf);
sprintf(format, "%%%ds\n", length/2 + (buflen+1)/2);
printf(format, buf);
}
return 0;
}
--
James C. Hu (jxh@math.ksu.edu), 1804 Denholm Dr., Manhattan, KS 66502
I speak for me, the whole me, and nothing but for me. So help me me.
From jxh@math.ksu.edu (James C. Hu)
Subject: Re: Centering lines in vi
Date: 29 Jan 1993 01:40:31 -0600
jxh@math.ksu.edu (Me) wrotes:
>There is probably already a package that does this, but I'd put this in
>as an example on how to build useful simple filters for vi. At the end
>of this post is a simple program that centers text. Compile it and
>install it in ~/bin/center, or whatever.
>Then, make the following map:
>:map == !!center^M
>(the ^M represents the result of hitting CTRL-V followed by CTRL-M)
>Presto, you have a pseudo center "operator". Now you can do a == to
>center a single line, or a 5== to center the next 5 lines.
Whups, major bug in my center program. Here's a fixed version.
/* File: center.c
* Creator: James C. Hu (sirius@matt.ksu.ksu.edu)
*
* Description:
* Centers lines of input.
*
* Caveats are that lines cannot be longer than the specified
* centering line length, if they are, then they may be truncated,
* and that the default centering line length is 72.
*
* Copyright:
* This program is placed into the public doman.
*
* Date Started: Thu Jan 28 15:33:44 CST 1993
*
* Change Log:
* Date: Fri Jan 29 01:36:57 CST 1993
* Fixed a bug in the inner loop: buf would creep up to the end of
* its allocated space.
*
*/
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
static int length = 72;
static char *buf;
int main(int argc, char *argv[])
{
char format[10]; /* should be enough */
int buflen;
char *p;
switch(argc) {
case 2:
length = atoi(argv[1]);
if (length == 0) length = 72;
case 1:
break;
default:
fprintf(stderr, "usage: center [width]");
exit(1);
}
buf = malloc((length + 2) * sizeof(char));
while (fgets(buf, length+2, stdin) != NULL) {
if ((p = strrchr(buf, '\n')) != NULL) *p = '\0';
p = buf;
while (isspace(*p)) p++;
buflen = strlen(p);
sprintf(format, "%%%ds\n", (length + buflen)/2);
printf(format, p);
}
return 0;
}
--
James C. Hu (jxh@math.ksu.edu), 1804 Denholm Dr., Manhattan, KS 66502
I speak for me, the whole me, and nothing but for me. So help me me.
From lind@eng.umd.edu (Charles A. Lind)
Subject: vi? CAPS --> small
Date: 3 Feb 1993 13:29:46 GMT
Hi,
Within vi is there a way to change all capital letters to small
letters, or vice versa. Is this possible?
Thanks
Charles
lind@eng.umd.edu
--
------------------------------------------------------
Charles Lind -- lind@eng.umd.edu
Department of Aerospace Engineering
University of MD, College Park, MD 20742
From edwin@integow.integrity.nl (Edwin Koedam)
Subject: Re: vi? CAPS --> small
Date: 4 Feb 93 08:10:50 GMT
Charles writes:
:
: Hi,
: Within vi is there a way to change all capital letters to small
: letters, or vice versa. Is this possible?
:
: Thanks
:
: Charles
: lind@eng.umd.edu
To change capital letters into small ones, just use:
:%s/./\l&/g
To change small letters into capital ones, just use:
:%s/./\u&/g
\l& means: Change the found character to lowercase.
\u& means: Change the found character to uppercase.
Hope this helps
Edwin
From hansm@cs.kun.nl (Hans Mulder)
Subject: Re: vi? CAPS --> small
Date: Thu, 4 Feb 1993 12:00:02 GMT
In <1kohcaINNk41@mojo.eng.umd.edu> lind@eng.umd.edu (Charles A. Lind) writes:
> Within vi is there a way to change all capital letters to small
>letters, or vice versa. Is this possible?
To downcase everything:
:%s/.*/\L&
To upcase everything:
:%s/.*/\U&
HansM
From jmd@bealfeirste (John Downey)
Subject: Re: vi: Including blank line in search string?
Date: 4 Feb 93 13:10:28 GMT
Reply-To: jmd@muppet.bt.co.uk
J R Evans (ngse18@castle.ed.ac.uk) wrote:
+---------
|
| I work on a range of different machines, mostly using vi on Unix systems,
| for the usual reason that it's always available. One trick which has
| always escaped me is how to search for a string which extends over a
| line end (indeed, this seems to be a problem for all the standard
| Unix search utilities). As an example of the requirement, I was
| looking through my mail folders for the "start of message" sequence --
| "<blank line>From ". Is there a solution within (generic) vi?
|
| Russ
|
+---------
You can't search for a pattern that crosses a line boundary; but you
can specify a match at the beginning of a line, by typing:
/^From /
(The final '/' isn't actually needed, but I've put it in to show the
preceding space.) This will solve the particular problem you mention
because most mail transfer agents will change a line starting with
"From" in the body of a message to ">From" anyway.
Regards,
John Downey
Work:
Paper mail: MLB 1/21
BT Research Labs
Martlesham Heath, Ipswich, Suffolk, England
Mail: jmd@cyclone.bt.co.uk
Telephone: (UK) 0473 649626
(international) +44 473 649626
Home:
Paper mail: 55a Sutherland Sq., London SE17, England
Telephone: (UK) 071 708 1299
(international) +44 71 708 1299
From jmd@bealfeirste (John Downey)
Subject: Re: replace <character> with CR?
Date: 4 Feb 93 14:54:14 GMT
Reply-To: jmd@muppet.bt.co.uk
Charles A. Lind (lind@eng.umd.edu) wrote:
+---------
|
| I have a line of words in the form:
|
| joe, pete, ron, mary, rich, nick, ted
|
| and I would like to change all the ',' to <CR> so that
| I get
|
| joe
| pete
| ron
| mary
| rich
| nick
| ted
|
| I guess something of the form
|
| :1,$ s/, /<CR>/g
|
| is what I am looking for.
|
| In general I guess I am looking for the representation for <CR>,
| <TAB>, etc. I looked in cs.uwp.edu but I could not find this.
|
| Thanks
|
| Charles
|
+---------
In vi, type
:s/, */^M/g
You have to type control-V followed by control-M to get the ^M. An
ASCII newline is actually control-J, not control-M, but vi won't let
you insert control-J into a command line. It's a bit illogical.
In xvi, type
!!sed 's/, */\^J/g'
You have to type control-V followed by control-J to get the ^J.
Regards,
John Downey
Work:
Paper mail: MLB 1/21
BT Research Labs
Martlesham Heath, Ipswich, Suffolk, England
Mail: jmd@cyclone.bt.co.uk
Telephone: (UK) 0473 649626
(international) +44 473 649626
Home:
Paper mail: 55a Sutherland Sq., London SE17, England
Telephone: (UK) 071 708 1299
(international) +44 71 708 1299
From davisonj@en.ecn.purdue.edu (John M Davison)
Subject: vi questions. HELP!
Date: Mon, 1 Feb 93 14:41:02 GMT
Help! The following vi questions are plaguing me:
1. Is there a way to do the equivalent of
:s/<tab>/<space>/g
without it failing (i.e. stopping the macro in progress) if no tabs are
found?
2. Is there a way to encode the "|" character in a "map" command? Presently,
when I attempt to include the "|" character in a "map" command, vi ignores
the "|" and everything else that follows it in the line, as if it were a
trailing comment delimiter.
3. Is there any standard, terminal-independent way of mapping sequences
initiated by function keys, i.e. "<F1> k"? (My current way of mapping these
sequences is on a terminal-by-terminal basis. No mnemonics, just raw
sequences.)
I want to map function keys, application keypad keys, and arrow keys in vi,
but I don't know of any non-terminal-specific mnemonics that I can use for
the mappings. Are there? I don't see anything in the ex/vi references I've
looked at.
The following .exrc (see end of this article) works, but only for a
vt100-series terminal. How can I make this work more universally (i.e. with
WYSEs and other terminals)? Also, with an LK-201 keyboard (DEC vt2xx and
up), how do I specify the PF keys versus the F keys? Is there any standard
way of doing it, or do people just tweak their termcap/terminfo entries as
they go along?
4. What sequences of ASCII and non-ASCII (8-bit) characters can and cannot be
mapped by the "map" function? It seems that any sequence that contains
either a space or a LF character, for example, cannot be mapped.
5. Is there any facility in vi that allows one to map a key, in append mode, to
something which, unlike a macro, can invoke some user-defined algorithm
complete with conditional branches, loops, etc.? I am looking for something
that would do the vi equivalent of mapping a key to a TPU function (for
those familiar with Digital Equipment Corporation's TPU).
6. Is there a way to make the "autoindent" feature put in spaces instead of
tabs?
Coherent answers to any and all of these questions are appreciated!
I'll post a summary if someone wants me to. In the meantime, here is my .exrc
file (if anyone is interested) and, after that, a file containing function key
sequences for various terminals and terminal emulators:
-------------------------------------------------------------------------------
begin 0 .exrc.Z
M'YV0(@(*'$BPH,&#"!,J7"A"@0@0$"-&3`(B3!L09]ZD<7,&!)TW(.#4H0-B
MSILV94"(>>.F3`LT9<*0*4,&Q)B3*-W0F0,"IIR484C2@>GQ#1P0;\QX)`JB
MX4,79?#(&0/"3!HV*>OHO`J"XIDR),.H!$NGC)RJ9<JP0:H4S9L[2U/:"2,G
MS9LZ/*%*I7JS39LP;LCPE-C4(8@[;^2L<4&XL>/'D"-+GAS1*>7+F#-KAFCY
M,16B5N7,$8IF8T>*<]S685/S)\HV8LR"2,-S:-"X36VBH1MF3-FSM$'@I5G9
M<!B>8NG("7/5M$V<972R4#ER-LDQ@$^0C"U\#O&-%9O^A?.P[]_`T^=L')-R
M:$K.AL<?OKIVZ,8U2X.>X`F'+LFDN,VDWD\U>1=''=&QQQ@(0?!D!ET5\431
M&FZ\-1UAEKGWTWX@5'A8&'D4%5)UR2W7'$?/^17=?VZ$)\)XY>$$&!D+7M;9
M9CCFN-F-C07!ADG3B?5B&.2E>%Y-1ID55!D\@6?>C""T\<9,PKF!U1P\Y7$7
M"#-9U9)UA3UT1QI#B4=D""),!]X=I8V!ADW'I40F4G`H65:3+6[DG1PD23G3
M@E2`U.5&94QG1F*-61:517!@9:A6OMG5XAIEA!A#>B":>=0(,8#@PJ<B+$@1
M&2QI!P*%;_64JGR(K5;33&&L9=F89=I!QPPRP##'=&RFX69/8=B1TDIE0F%$
M59#2(2E/E.;!4Q!.$`'"3V>L!J$9R4IZ:J5SU&@9$FJQ,=VHI9)4AK"35@B7
M6W!]5-$8[&&)FQMUH%075<WV5U.S/+$4GJTQP`"#MX;I:/#!D?%(6*"SN3$&
M&W50"=@;&E9UE9PMVI=75%--YQX(;!!ZV%VLC36992*89#%6;EA41J@(QTR9
MPC+7C"/-$3V!QG1YQ(2&#BJQ`1A^(;>$W$_A5=B"A^")I==4*Y=1(V8XVVSU
MS`XQI/767'<MD`+>S79&A3]AYQW8*56(TAQGH#TM3<O=X?9/<"1&1P\Q9.WU
MW@09MD2E($Q1QH$)E@'T%S);-H2,@8'0Q)2&@U!%8&85W1Y1*Z:!M.6,618$
M''4V_OA,0$.Z&T?$[:@WWZPK(!\(B(.@PQPO@/#"%R^<T<#L+WCQA0JW[T[[
M[R0$OSKK?/L-N."$.YP2"@`+G`+0QG8:.]8/+>X7E'Y&/OE,<EB.VQAUR/&3
M3B/+06.8#((>74W=`_U]Y2)_3+[Y*Z:_?IC((^\ZD1#9P!.@@+@T?&$#,3G@
M_^`0`A`(D(`.%((!$1B&XW'-,$P@5`N,0!\0H*!Z54D!__:VP``.4"EO:,`&
MUK"&$/3!*FQ@PQ<L-X<&](X$#2!#`Q;8P`<J90,I7&$+7TB?&1*JAC?,80/6
M$`006-!_#RD"'NI4EYS0(58>D4-2E#*:.IA!*4[IWT#T!@)CR4`E$4'!3=P@
M+#[Q1'SN6@EK1/@U^0@P"F*0'>V\\`(N<,$,0A#>"XKG1S-(88<"*:,1SIB&
M-*ZQC3L!6?U`0J98^8J.`2GA'1O).SX6,@F").0?#TE&,T[+D2R!Y!LG.:V3
M``:3#;'C$Z)PED[V<90['$\/!YC'/PJ!APX<8"/_F`1@/O`LHS3F`(_B`BA`
MH91&Z%0>U9A*LT02,>H3D1S)`,L2!A,*>4R#+RDXR@U`LU.-I"8;K<D3;-;$
M794,V1BZ^;H'-E*<9D@".0UISD2"<`\>3)(;D!,2YIP%0&)8SA@HM1-ZGNF;
M`-U#'S:0AG."`*`H$"A!^Z,YMA3T?.[QSAP<RD"(>C`%%(7F&3&JT?!P]*!*
M26AO&(JG\-PA4[8A"4S8`(=VDNE-0PB)%L^P'+^8AJ2[C$)$-S`[H(Q$(Y33
M20."T(`^5'4#+HQ*?P*SQ*Q.<48-(`$>FMJA-X3AJ1N9B52;&!%OWA&@0=@#
M4\-VUH^D=453K>I5O;I5'0Y1JV`5*UDK5%>HJI4.4Y7($\6(D,4RUB".?6S?
M)$M9,1;,,9])R4^.XZ^<=H5+Y8H2`#^&+8<IRU_\XI+FRN`;-H0(+\[Y6'$>
M(H(1F.$A%;KB:?-4F]V0A"(6:=AOF%26FH`'MB@J;:10RZT(E61P"'*>1"RS
M$3*E(2B)V55%&I=;Y_:E46!)B8&B&Z^&Q:4-WF&#L+H%$1\!"3>_:0-VCJ(H
MG=2%2:(-$7?NH$44A6$EU5'N;K?EK.WFX:9YF!K"PEC9!GLM/@`$`:=``)8Q
M*/AJ5K.,+B7<J0I?&,,U8["#1\P0PPRA?"!U;5S")F!MI994;C`5J0QL'XZX
M(+(DSG$F7S>",\[&G!ON<400X,T1S``B:0#R0XT\Y"+3`,E*+ND(G@P1(NMX
MLE?^6I:UO.4N5PT$F0W;7\:@Q:/)A0X!@T$+YE"G,:3!*F.8CE:4M1:*8*=%
M7D)2=3ZFE32T<0Y8U'!+I.0&7SD(42%-";\^]6$0)^RRCHZT8[Z<6=&2^0UF
MM@F*5Z1B\)#V#3%\BW,2`SZ@W<PP=8!#"^BB1;@T2](9-@RI[N"&59LO5:^&
M=<PL@Q4ST,'6K2:PKG=MF+J<`0V_9C6N`3=L@UF&2(WR55!<7"E]@0`&S=;,
MLT$GSVDS-P_6[E2VJ68<;DM[P/F2"0A\/&[L5<3<V$%WM=5]Y':[&]K=EC>X
MU4UE>TMFV]&.-[7W79,:^/MDY0ZXMR<U[YK8X.#_3GB^!V[M&T#\T0_!][DI
MKFX<7!PR`)_XMZV=@X\_)N0;'[FZ&_UQE`M<Y35I@<DG+?&4,YS@(+C0S*=;
M\Y??W-I%<`(5BB"%G;//Z`O&L9<IJ\PFKK""&Q:@$!RH!J@_5(#2VL!NE!G4
M#0A-F4>!@3+C`(*\1?T)9Y&!,GDR`V62A`;*K`,(:J!,.X#`!LJ$RPV4B0<0
8X$"9(<J!,EMTX[-?I`7*7`L+E-D$$.P0
`
end
-------------------------------------------------------------------------------
begin 0 fkeys.Z
M'YV08<BTJ0%B"IPR8]*$80-B29D\<Q2TF$BQHL6)"A0XS`.BH\>/'I_4H0-G
MI,2)(%-VO-A"`9DW=]RT""-'#LR43(PHJ`-G9LV;*L>\<4/')IL62Q2P*6.&
MCD^;=U(*)6JT!1(%<M*<0>.4)E204XN^.<I$`9HW;<JH!#M4[%$O"H3(*1-F
MS5J/;M[009/&S1D%2,K,!9%DSMV\>_O^A6+SS%V\>OGZ!8&"SILS9Y8:)I-F
M#APV83B^,0,BK-'2:&B&&4-'\)P4"HK("3-'+9.^:D$BENP8!9LW8Q:RX2B8
M=AG#8U+/9NT:A&7G:-1FW4H'Q.C2=>3,>2,'MFSC(*"$.9/[XV[%E'\'9S,<
M1/':AI_OE:Z5JW728=R0`2&FS.^H8V2W77<9L63@@0@FJ.""!V8T%WE$R0!#
M00<EM%!##T7$($L9;?182".51,=)+7RXTD6QS5;;AZ:-U0(3E)G!71L@F%%&
M&63`MN&.//:XH(-EG"$A'A0BI!!#&VG88X</F0B"2"291)&3''ZWXF,MDA7C
MC#7>F*-+,,GD%5`?Y;133V-&%51;56FA%%-=_:3F1UFV4`56]<7Y%9ULNJC3
M66F96&<0!?IHZ*%+*C!%'6Z`,,,+-4QHD)$7)@E"7R#@T9H<-*)@!QTQP#!A
M&V^048:.B!K*)$=.M@JEB"2VVBJ'3,0@:ZM%3#$$"%N`((.C(/BA`!._WFIB
MKKOV^BL-P0X[@[''ZLJKKR`0)"P3S$+[&++3_FI#LTP0I.U=W"H+`@[@?CON
M6N52FP.X-ZS+KK2]/FOKM>C*F])Y?@W[KKX@M?OLL]>&"O!'`H/`K+!&V'JP
M1R@PND9>,;E@\1MV")85&:8V*@9';7!$Q15-@%`;'3S!9D2Q#U,F,<5N6.P"
MQAJGP7$9'H,L,LDFEX$R'"H_V[++;DP<ILPTUV1SQ_SI#,+()9^<L@)&9-MR
MN[8N3+6X5],+@JW64JUNU\E^#4*\#,<[--;G-FM$OF1/:^N[#/\;M[D3"BN%
MPRWS^Y<4+#_LMP)2"-UW9(H1;K7@B/<K!=>,)^;XV)'S1KC:ATO^-[HHA`''
M9RZ`P--3,*40[:Y/@$"H%)S/00<9H8^>INFG3[NZW94GOO>$*+@..PA+-47Z
M';3/BSH(1!!N<.>?LQ%Z\'J63J[7R>_-]\&#[_UK[Z^'/AU7PQ>?$K>I#Z'\
M]IZ##L+WT1-O_+3F[VTX]HW_'0.SW/_^4DSA;RMMZD)0'O[2YSP0[$],<A)?
MP+P6P+U!#F"#(U&J)DC!BF1D48V:`A2"((4AN"X,=$C#4`@#A5U-RD)(RM"E
M&J4IP73J4Z$:5:E.)<$*4E`C31K:6EXE)93H4"4<FH)EX-`1%-1*@0=KUZ\(
MIH`@G"$,F#*B#)`(,"4JK%F,>0,<#&/$&5!17U8,6Q7T\X8B8NN+\K+BMQAF
M$Z)0)EQH7)<5T26L(6B154:T01S'946Z*>`)!VG4&V^P1VTE[%X*$(_KU&)$
M'!026@G[%</ZLI\WYN"1QDH8$X<P$HC5"@:8E%7"M!88-A#QAPLLVZ_H2)DY
MA"%0M`%!N$"PAH>H['JHA-C+CG:QC"GM9CD#0<B>QC.I`8UJ@<ME$7=9L5[6
M#)A-$^;.HN:SJ1EA?LHDFM&:.3-?;HQI'Y,F,:GY,Y4M+IMLTYH1'JA,MH7-
M")1#I]=LA3:J82Z;(&`;':D&-WRRS8]&P)T\50F"O%'-8/C,I]=^A<B&X3*7
M5F1BPY()T85>46\Q>($(Q%.'VHC@AX.;`E^$M[=<AG2D3@&<2>NG*)2VH'`K
MU1SA9*!1QDQA#!\%*4L+I]&;&H4-(M`H$X"SAJ"*0"YT*6JKLD>#%]0R#W`(
M"`A$T(.<TD^F(DT#2<\9M]1A@7`U<.I#HKH?HV;.<EDE*3L?1C[K$,X&8H6J
M5$6@`JM"D*5I36D\NPH"-5PNKF2=Z@V,B@2TE,&NMSJI5E-ZS[7]#P1W(!P.
M`#M7'`25@+%#DYQJE[K53?:I@16!95_@N\P.STGM(E1>7]I/QQX/#X3+`67+
MF@.C0N$,58`#8F6E6)(*E*]Y4!X,9CM5&HB`!2;K'O#@=-KWI:YZH2*N"(R+
M7,PN5WAI>E^ODK?:W:&RK2.RGG1KL-MQ]3:E,7AH$A];A_-)UP;'3>[OV-?<
M\3TV?C&@*6CG"M_J-L][>1I>`MIEON[F][N/M8/R'K7?LL;`J$703WF==-Z7
MQ@";;'UL'`0H71G$M[0&#%-][7N\!MZOP_&U[@%'C#`&MG2Q%N;J>H\G!^6%
MM<%3G4%\-WH&(KAAPOXK\8M)&H.U5O&Q$<&Q"&!@U"2X80Y`%J5%A:5D%QB5
M"/Z)<JN(4(2R*-D)=:#14,>@5'E56`1@%C-1M4QAEBJY!6R&Y&,[Q1V3I:$-
MG^&(".`LLS30X02&N4,9TB"'+REY!7'.Y&/M@H(ZS^'.>9XJGRWF9T!#=M"%
MAHV2([RI1',6!"5KM!SLC.?V[%D$??YSH#']I2"PH3H)'1P1%$(J_2AS<';$
M\QNNA,K!N;HZ1Y@-'-#0:Y8J8"U.T(M:]@)"Z*@%QT\US%P\,Y3]<,8,-IH+
M4=ISA^@T2@1Y_6AG0$#`-.#(!0IP,@CLD`9R?PYG^R&5J9`KHU&7`0^O_$P9
MD,L7.H1P,O,!@1O"W)^Y[`?:*L345-3`*-:(T`T*N(.?B0UNE'X4#C8A0QW&
M<!R!$]PUH7L2L<7PACR@NX8V3+F/,@)#414)A1B"",H5M*JA\7!$4VH9A\H=
MG!".4':;#?*35*<`GH/PX2'F7W:="X(`&MWGC8(>BUM\O.0]'>GT73J)AVZ^
M#^J')OL!^IYJURM">9T,8$\Z`L<^O;(%\.QIE[K6VSZMY,&]T.L+\-Q50N!$
M-LRU0X>"WRF:QL=&P>\8+OSQI.!W&<OQL5,H>O/2T'.DXWA"0D\='"3_&<H?
M?80X5B_5A[[AJX-^K%(E_.A35V/3-PK'B5^]R3C/!L]#G9:HWX_C/0)>VMO>
M\KFOUH?:VE[7XUZN^]EK*H>N8./CN+%;3UUDG1_\UD8_4[ZO_.F1#X+?+C]U
MP:4^]T-.]]1!7/R!+5'FA9G]S[\^^,A=/QO:?WL<%\$)5"B"%/C^V"842N4`
MF"AW`!%E$"DO=R0QIR0\4G,M<W.QHG,H\G=#,R@@``0@,`2,MS(Z1(%!<($9
M&'OK0H%"X(%4LWOC0H&[@H%;LX%]<A0=2`0D"$\L2!4NTH%%$(/0IR\4:`0Q
M:'TZV((MT(%'$(/>)R\4B`0QB%`/0X%)D(2B=X)`V(%*D(2J!X4TZ((-D80@
MJ"T4"",JV#`F""T46#)?6&03&(4@X`1)J'PAB(;EDX$-!VMWI3F4T6TX`P+]
MQA],P1UJD1^1(1C'AUPB8AAO8!()]1&U$0=U@#,<-U44R&Q.\50>^%&T<6R'
MV!&_,1FQ)`*0V`)/]5$O<1QN<`+5L1!S$1`<`2N7V!&%6(J-PBV)N(ANT(AU
M-BB6>(FQR(@TQ!A](8=@)"V"-P7P%C<WD$AS80?A,1[E84C2H@0*X`3W5AWB
M01Z*UQ"`85@M4R=>0!EIX`)E$#I>X`6PX62&<1MNL(S,N"M%D&Y/=H'*\8N[
M<GA8QA#FB(YRMBN,-X_N2!/P"`)7H`!#L!3\Z%,W(DB*MBM9`)`".6KU^'B[
M0@7L6!MRX(L."0(;)@5E$&DSMCX9\8S*I@/.5B-C\1_H$6WD-AB8$G"N%"AP
ML&M^AG7^<709XQQE%'`-I@,9,8"U88!WT7(P@'*/81$1N8^CIA)0T#`*H(]#
:\(Y&N3(*21<,B1LI<90S0#@9V1Z/<90TH``P
`
end
-------------------------------------------------------------------------------
--
John Davison, davisonj@ecn.purdue.edu
"The next time you start to say, 'Purdue isn't as racist as some other places,'
bite your tongue. I've lived in the South [U.S.] all my life, and I have
never encountered as much racism there as I have here." -- Sumi Rebeiro
From dp80027@data3.sbil.co.uk (David Price)
Subject: Re: How to add blank lines in vi?
Reply-To: dp80027@data3.sbil.co.uk
Date: Fri, 5 Feb 93 08:27:17 GMT
In article 19086@newssun.med.miami.edu, emansell@miasun.med.miami.edu (Eric A. Mansell) writes:
>So, let's say you have a fairly long file and
>you want to globally add a blank line immediately
>before every line that begins with a ">" character.
>
Try the following:
:%s/^>/^M>/
where '^M' is generated by entering CONTROL V followed by CONTROL M and
'^>' is actually a caret followed by a right chevron.
Cheers,
Dave P.
From ciacovel@telesciences.com (Chris D Iacovelli)
Subject: Re: replace <character> with CR?
Date: Fri, 5 Feb 1993 15:51:23 GMT
In article <1klsekINNk9k@mojo.eng.umd.edu> lind@eng.umd.edu (Charles A. Lind) writes:
>
>Hi,
> I have a line of words in the form:
>
> joe, pete, ron, mary, rich, nick, ted
>
> and I would like to change all the ',' to <CR> so that
> I get
>
> joe
> pete
> ron
> mary
> rich
> nick
> ted
>
>I guess something of the form
>
> :1,$ s/, /<CR>/g
>
>is what I am looking for.
>
>In general I guess I am looking for the representation for <CR>,
><TAB>, etc. I looked in cs.uwp.edu but I could not find this.
>
>Thanks
>
>Charles
>--
>------------------------------------------------------
> Charles Lind -- lind@eng.umd.edu
> Department of Aerospace Engineering
> University of MD, College Park, MD 20742
How about this:
:1,$s/, /^V^M/g
^^^^
control-v then control-m
Works for me.
Chris.
================= VI it is not just an editor, it is a number. =================
From zz1bb@impending.ucsd.edu (Barry Brown)
Subject: Re: vi? CAPS --> small
Date: 5 Feb 93 16:34:26 GMT
In <1663@integow.integrity.nl> edwin@integow.integrity.nl (Edwin Koedam) writes:
>Charles writes:
>: Within vi is there a way to change all capital letters to small
>: letters, or vice versa. Is this possible?
>To change capital letters into small ones, just use:
> :%s/./\l&/g
>To change small letters into capital ones, just use:
> :%s/./\u&/g
Pressing tilde (~) over a character will change its case and advance the
cursor to the next character. Just hold down the tilde key and swoop over a
few sentences to change all the letters to the opposite case.
--
Barry E. Brown -- \ UCSD Instructional Computing Center
bebrown@ucsd.{edu,uucp,bitnet} \ Anime Stuff FTP Server administrator
Somewhere in San Diego, CA..... \ (ftp network.ucsd.edu [132.239.254.203])
"Stimpy, sometimes your wealth of ignorance astounds me." -- Ren
From ciacovel@telesciences.com (Chris D Iacovelli)
Subject: Re: Why !!
Date: Sun, 7 Feb 1993 15:27:41 GMT
In article <1993Feb4.003728.13763@dragon.acadiau.ca> 911288c@dragon.acadiau.ca (EDwin Chung) writes:
>Dear friend,
>
> I still don't find anything work for centre text
> in vi !!
> Any help ??
> EDwin
>
EDwin,
Try adding this to your .exrc file:
------- snip --------
map [c >>d0$maKV{{\q
map K 80a
map V 80|D
map {{ `a
map \q lxd0:s/ / /g$p
------- snip --------
It works for me.
cdi.
=============================
Christopher D. Iacovelli
Member, Technical Staff
TeleSciences CO Systems
Moorestown, NJ 08057-1177 USA
ciacovel@telesciences.com
=============================
From popaul@cs.mcgill.ca (Paul TERRAY)
Subject: Re: vi? CAPS --> small
Date: 10 Feb 93 20:36:13 GMT
Reply-To: popaul@binkley.cs.mcgill.ca
> In <1663@integow.integrity.nl> edwin@integow.integrity.nl (Edwin Koedam)
writes:
> >To change small letters into capital ones, just use:
> > :%s/./\u&/g
For more detail, \u modifier just change the first letter of the match.
So if you want all word to begin by a upper case letter:
:%s/[a-zA-Z]*/\u&/g
otherwise, you can use \U modifier like
:%s/.*/\U&/g
will change everything to upper case.
Paul
From nh@cbnewsg.cb.att.com (nicholas.hounsome)
Subject: Re: VI with tags stack feature
Date: Fri, 12 Feb 1993 11:32:29 GMT
>From article <1993Feb11.190457.13940@bnr.ca>, by mschee@bcarh600.bnr.ca (Michael SamChee):
> Does any one have access or know of any version of VI for
> HP workstations, that has the 'tags stack' feature ?
>
> ie, you can invoke tags recursively and be able to
> pop back to the previously invoked file.
>
> Thanks very much in advance,
> Michael.
elvis has tagstack and I believe that it is supposed to work
on HP.
From watts@cs.scarolina.edu (Chris Watts)
Subject: Changing case of a word....
Date: 12 Feb 93 02:07:37 GMT
Could anyone out there tell me how to change the case of a single word to all
upper case or all lower case. I would like to do this for a single word not
all the words in the document. I would appreciate any feedback. Thanks.
Chris
From dattier@genesis.MCS.COM (DWT)
Subject: Re: ctrl-d in vi's insert mode
Date: 9 Mar 1993 16:04:47 -0600
Reply-To: dattier@genesis.mcs.com (David W. Tamkin)
eleleetk@nuscc.nus.sg (Teng-Kiat Lee) wrote in
<1993Mar9.041852.13666@nuscc.nus.sg>:
| I have a problem getting one of the 'standard' vi macro to
| work. The macro works in insert mode and it is supposed to
| give me a switch structure when I type sw'. The (for tabbing
| one 'sw') works but the (for deleting one 'sw') didn't. It
| seems like all the macros defined in the .exrc file with the
| didn't work as planned. Has any one any idea how this can
| be corrected? I am quite sure I did the right macro. The macro
| in question is given below:
| map! sw' switch () {^M^Tcase : /**/^M^Tbreak;^M^D^D}
| p.s: I did a manual mapping while in vi and it worked.
Now there is a big clue; commands in .exrc can get rescanned and special
characters in them may need extra escaping that they don't need if you
define a mapping or map!pinFrom dattier@ddsw1.mcs.com (David W. Tamkin)
Subject: Re: set nu
Date: Fri, 29 May 1992 02:25:12 GMT
[Please post follow-ups to comp.editors.]
wiggins@osiris.cso.uiuc.edu (Don Wiggins) wrote in
<Boz3sw.LK0@news.cso.uiuc.edu> in comp.unix.questions:
| Haven't been able to find this anywhere. In vi, ":set nu" numbers the lines
| in the file. However, I have never been able to figure out how to
| unset this feature, short of getting out of the file and getting back in.
:set nonu
Here's a hint. In vi, ":set" displays any options you have changed from the
defaults, but ":set all" displays the current states of ALL options. If you
do ":set all" before ":set nu" you will see "nonumber" in the listing. After
":set nu," ":set" and ":set all" both include "number". After ":set nonu,"
":set all" has "nonumber" in it again, and "number" is gone from ":set."
So if you want to know how to undo an option, look at :set all before you
change it; then you'll see how to change it back. Generally, if an option is
a

180
comp.editors/modeline Normal file
View File

@ -0,0 +1,180 @@
From b.keck@trl.oz.au (Brian Keck)
Subject: modeline -> Modified
Date: Wed, 10 Jun 1992 04:59:34 GMT
If I have even a trivial modeline, eg :
vi:map , j:
with a minimal .exrc :
set modeline
& no ~/.exrc or EXINITRC,
then when I start vi the file is immediately marked [Modified].
This seems a bit repulsive. Is there a better fix than :
vi:map , j|w!:
Thanks,
Brian Keck
b.keck@trl.oz.au, phone +61 3 253 6407, fax +61 3 253 6362
Network Services & Signalling, Telecom Research Laboratories
770 Blackburn Rd, Clayton Victoria 3168, Australia
From keck@wembley.trl.OZ.AU (Brian Keck)
Subject: Re: modeline -> Modified
Date: Thu, 11 Jun 1992 05:08:18 GMT
I asked :
>If I have even a trivial modeline, eg :
> vi:map , j:
>with a minimal .exrc :
> set modeline
>& no ~/.exrc or EXINITRC,
>then when I start vi the file is immediately marked [Modified].
>This seems a bit repulsive. Is there a better fix than :
> vi:map , j|w!:
I forgot to say this is SunOS 4.1.1 (:version -> Version SVR3.1)
Thanks,
Brian KecFrom
From: buboo@alf.uib.no (Ove Ruben R Olsen)
Subject: Re: how to set vi options in file to be edited?
Date: Tue, 26 May 92 21:50:34 GMT
Lyndon C. Lim writes:
>a friend told me once that vi used to be able to read
>either the first or last few lines of a file, in a
>certain format, and know that those lines were meant to
>be executed as vi commands. i haven't been able to
>find this in any documentation. i don't remember seeing
>it in the faq either. usually, i have ts=80, and sw=4.
>however, for certain files, such as shellscripts, i would
>like ts=4, sw=4.
>
>is this possible? i would prefer not to have local .exrc
>files since the directory also contains files for which
>i don't want ts changed.
Well... in your $HOME/.exrc you must have
:set modeline
or else this will not work.
You may also set the $EXINIT to the appropriate.
Taken from Marten Litmaath VI refference, Version 7:
modeline | When you read an existing file into the buffer,
| and this option is set, the first and last 5
| lines are checked for editing commands in the
| following form:
|
| <sp>vi:set options|map ...|ab ...|!...:
|
| Instead of <sp> a <ht> can be used, instead of
| `vi' there can be `ex'. Warning: this option
| could have nasty results if you edit a file
| containing `strange' modelines.
This is IMO a MUST of a document if you are not fully aware of all the
quirks of VI.
It IS a quick refference, but one of the good ones around (no offence
to the other ones !)
For a fuller discussion on this issue, fetch the file called:
vi.startup.d.Z
from the VI archives.
-------
>From one of the INDEX files at the VI/EX archives around the world:
For starters (and other interested peoples :-) I recomend:
vi.intro.Z Introduction on Display Editing with VI. UCB-dist. A Must.
vi.reference.Z VI reference. Version 7. A Must.
ex.reference.Z EX Reference Manual. UCB-dist. A Must.
vi.apwh.ms.Z VI Command & Function Reference. UCB-dist.
vi.chars.Z Apendix: character functions. UCB-dist. A Must.
vi.intro.ps.Z vi.intro in PostScript format. UCB-dist.
vi.reference.ms.Z VI reference for typesetters.
There are several other courses/guides for starters. Check out the INDEX
file, or take a look at the FAQ-2 posted at the beginig of this month.
If your news expire works, it should be availible. If you can wait a week
the INDEX files will be posted again.
The VI/EX archives can be found at:
Europe:
Main site: alf.uib.no (129.177.30.3)
Filearea: pub/lpf/misc
Peak hours: 07.00 am GMT to 03.00 pm GMT
Japan:
Mirror site: utsun.s.u-tokyo.ac.jp (133.11.11.11)
Filearea: misc/vi
Peak hours: 01.00 am GMT to 09.00 am GMT
USA, Canada and Mexico:
Mirror site: cs.uwp.edu (131.210.1.4)
Filearea: /pub/vi
Peak hours: None.
Australia, NZ and the rest Down Under:
Main site: monu6.cc.monash.edu.au (130.194.1.106)
Filearea: /pub/Vi
Peak hours: Not relevent
For more information about the files at the archives and the archives
itself, please read one of the FAQ for Comp.Editors.
If you are in a hurry you may fetch the INDEX file.
If you need more information, you are welcome to mail Ove.R.Olsen@uib.no.
\Ruben.
--
Ove Ruben R Olsen, Professional VI user. EMAIL: Ove.R.Olsen@ubb.uib.no
Maintaining the Largest VI/EX-STUFF Archive in the WORLD (alf.uib.no) and
the Comp.Editors FAQ file. If you have information about editing, new editors,
please get in touch with me. This does not apply to EMACS type of editors.
From soh@andromeda.trl.OZ.AU (Kam Hung Soh)
Subject: Re: how to set vi options in file to be edited?
Date: Tue, 26 May 1992 22:26:22 GMT
lyndon@angelo.amd.com (Lyndon C. Lim) writes:
>a friend told me once that vi used to be able to read
>either the first or last few lines of a file, in a
>certain format, and know that those lines were meant to
>be executed as vi commands. i haven't been able to
>find this in any documentation. i don't remember seeing
>it in the faq either. usually, i have ts=80, and sw=4.
>however, for certain files, such as shellscripts, i would
>like ts=4, sw=4.
>is this possible? i would prefer not to have local .exrc
>files since the directory also contains files for which
>i don't want ts changed.
You need to add this to your .exrc file:
set modeline
Every file can have vi commands in the following format in the first or
last five lines:
vi:command:
The whitespace and colons seem necessary for our version of vi running
in SunOS 4.1.1. I found the modeline command in the ``Vi Manual'' by
Sailer and Litmaath; it wasn't in the SunOS 4.0.3 documentation.
For example, my LaTeX files have the following line in the start (the
percent symbol is a comment in TeX):
% :source $HOME/.ex

294
comp.editors/multiple Normal file
View File

@ -0,0 +1,294 @@
From jafo@miranda.accum.com (Sean Reifschneider)
Subject: Re: Editing multiple files in vi
Date: Thu, 24 Jun 1993 05:42:33 GMT
In article <C9156L.44K@cbfsb.cb.att.com> vinlai@cbnewsb.cb.att.com (vincent.lai) writes:
>Let's say I wish to edit all files ending in '.c'
>
>I would enter 'vi *.c', proceed with editing the first file, press 'ZZ'
>to save and enter ':n' to move on to the next file.
You can always do something like:
map q :w^M:n^M
where ^M is Control-M. Then just press 'q' to go on to the next file.
Sean
--
"If you were happy every day of your life, you wouldn't be a human being...
You'd be a gameshow host." -- Heathers
Sean Reifschneider, Supreme hack
From hansm@wsinti06.info.win.tue.nl (Hans Mulder)
Subject: Re: Editing multiple files in vi
Date: 24 Jun 1993 21:19:37 +0200
In <C9156L.44K@cbfsb.cb.att.com> vinlai@cbnewsb.cb.att.com (vincent.lai) writes:
>I would enter 'vi *.c', proceed with editing the first file, press 'ZZ'
>to save and enter ':n' to move on to the next file.
>Question: Is there a set of keystrokes/commands that will enable me to
>both save the current file and move on to the next one? I tried ':wn'
>but vi burped. Thanks ...
You could use ':w|n'. you could also do ':set autowrite' (or 'se aw'
if you hate typing). This instructs vi to automatically :w whenever
that seems like a good idea (e.g when you do :n or :! or ^Z, but not
if the file wasn't modified).
You could also consider putting the string 'set autowrote' in a file
named .exrc in your home directory. This has the effect of setting
the option every time you start vi. Type ':se noaw' to shut it off.
--
HansM
From hansm@wsinti06.info.win.tue.nl (Hans Mulder)
Subject: Re: Editing multiple files in vi
Date: 24 Jun 1993 21:27:04 +0200
In <C94Kqo.Krq@encore.com> tma@encore.com (Thanh Ma) writes:
>jafo@miranda.accum.com (Sean Reifschneider) writes:
>>In article <C9156L.44K@cbfsb.cb.att.com> vinlai@cbnewsb.cb.att.com (vincent.lai) writes:
>>>Let's say I wish to edit all files ending in '.c'
>>>
>>>I would enter 'vi *.c', proceed with editing the first file, press 'ZZ'
>>>to save and enter ':n' to move on to the next file.
>>You can always do something like:
>> map q :w^M:n^M
I wouldn't use the letter 'q'. Being fumblefingered, I occasionally hit
it accidentally.
>>where ^M is Control-M. Then just press 'q' to go on to the next file.
Note that you have to type it as control-V control-M.
>How do you map to go backward ? (in a circular fashion may be)
You can get back to the start of the list by typing :w (if necessary)
and then :rew . The command :ar displays the list of files, with []
around the name of the one you're currently editing.
Unfortunately, there's no :prev .
HansM
From matthew@lenny.cs.mun.ca (Matthew J. Newhook)
Subject: Re: Editing multiple files in vi
Date: Thu, 24 Jun 1993 12:39:06 GMT
jafo@miranda.accum.com (Sean Reifschneider) writes:
>>I would enter 'vi *.c', proceed with editing the first file, press 'ZZ'
>>to save and enter ':n' to move on to the next file.
>You can always do something like:
> map q :w^M:n^M
>where ^M is Control-M. Then just press 'q' to go on to the next file.
Well, the command sequence
:w|n
will also work. | being the command seperator.
>Sean
>--
>"If you were happy every day of your life, you wouldn't be a human being...
>You'd be a gameshow host." -- Heathers
>Sean Reifschneider, Supreme hack
Matthew
--
Matthew Newhook (matthew@engr.mun.ca) | "...get on with the fascination
Faculty of Engineering and Applied Science | the real relation, the underlying
Memorial University of Newfoundland, Canada | theme" - Limelight, Rush
From bill@bilver.uucp (Bill Vermillion)
Subject: Re: Editing multiple files in vi
Date: Sun, 27 Jun 1993 14:32:01 GMT
In article <20cv68$pgj@wsinti06.info.win.tue.nl> hansm@wsinti06.info.win.tue.nl (Hans Mulder) writes:
>In <C94Kqo.Krq@encore.com> tma@encore.com (Thanh Ma) writes:
>>jafo@miranda.accum.com (Sean Reifschneider) writes:
>>>In article <C9156L.44K@cbfsb.cb.att.com> vinlai@cbnewsb.cb.att.com (vincent.lai) writes:
>>>>Let's say I wish to edit all files ending in '.c'
>>>>
>>>>I would enter 'vi *.c', proceed with editing the first file, press 'ZZ'
>>>>to save and enter ':n' to move on to the next file.
>>>You can always do something like:
>>> map q :w^M:n^M
>I wouldn't use the letter 'q'. Being fumblefingered, I occasionally hit
>it accidentally.
>>>where ^M is Control-M. Then just press 'q' to go on to the next file.
>Note that you have to type it as control-V control-M.
>>How do you map to go backward ? (in a circular fashion may be)
>You can get back to the start of the list by typing :w (if necessary)
>and then :rew . The command :ar displays the list of files, with []
>around the name of the one you're currently editing.
>Unfortunately, there's no :prev .
With a couple of more keystrokes you can simulate :prev is you use
less.
less the files you wish to edit. When it comes up, or when you search
to the part you want in the file, v will put you in to vi. Then a :wq
will take you back to less and then the N and P will take you to next
file or previous file. Not the answer, but it may be a solution if
you need to invoke multiple files and perhaps not edit them all. You
can get to all in the list that way.
--
Bill Vermillion - bill@bilver.uucp OR bill@bilver.oau.org
From bspahh@gdr.bath.ac.uk (Andrew Henry)
Subject: Re: Editing multiple files in vi
Date: Mon, 28 Jun 1993 14:29:32 GMT
In the referenced article, hansm@wsinti06.info.win.tue.nl (Hans Mulder) writes:
>In <C94Kqo.Krq@encore.com> tma@encore.com (Thanh Ma) writes:
>>How do you map to go backward ? (in a circular fashion may be)
>
>You can get back to the start of the list by typing :w (if necessary)
>and then :rew . The command :ar displays the list of files, with []
>around the name of the one you're currently editing.
>
>Unfortunately, there's no :prev .
Try <ctrl>6, or possibly <ctrl><shift>6
For me that toggles between the last two files that have been
edited in a list. It also remembers the cursor position.
If you have altered the current file you might have to write
it out first.
Andrew Henry
bspahh@gdr.bath.ac.uk
From darren@hunan.rastek.com (Darren Hiebert)
Subject: Re: Editing multiple files in vi
Date: Wed, 30 Jun 1993 14:54:52 GMT
In the referenced article, hansm@wsinti06.info.win.tue.nl (Hans Mulder) writes:
>In <C94Kqo.Krq@encore.com> tma@encore.com (Thanh Ma) writes:
>>How do you map to go backward ? (in a circular fashion may be)
>
>You can get back to the start of the list by typing :w (if necessary)
>and then :rew . The command :ar displays the list of files, with []
>around the name of the one you're currently editing.
>
>Unfortunately, there's no :prev .
I recommend getting VIM. It's the best vi clone (superset) going.
It has a "previous" command (i.e. ":pre[vious]") and everything else.
--
-------------------------------------------------------------------------------
Darren Hiebert (darren@hunan.rastek.com) "Made entirely from recycled materials"
-------------------------------------------------------------------------------
From darren@hunan.rastek.com (Darren Hiebert)
Subject: Re: View Content of Buffer [VIM can do this]
Date: Wed, 30 Jun 1993 15:23:25 GMT
In article <1993Jun30.075639.5512@alf.uib.no> chun@eik.ii.uib.no (Chunming Rong) writes:
> Does anyone know how to view the content of the buffers within VI?
> Emacs has such function.
VIM (VI Imitation) can do this (i.e. ":di[splay]"). This shows the contents
of all numbered and named buffers.
VIM, the best vi clone (superset) in the known universe!
Comes complete with source.
(Yes, I am a enthusiastic advocate)
--
-------------------------------------------------------------------------------
Darren Hiebert (darren@hunan.rastek.com) "Made entirely from recycled materials"
-------------------------------------------------------------------------------
From hansm@wsinti07.info.win.tue.nl (Hans Mulder)
Subject: Re: Editing multiple files in vi
Date: 2 Jul 1993 13:53:41 +0200
In <C9Fw3H.7nn@hunan.rastek.com> darren@hunan.rastek.com (Darren Hiebert) writes:
[ I wrote, about vi: ]
>>Unfortunately, there's no :prev .
>I recommend getting VIM. It's the best vi clone (superset) going.
>It has a "previous" command (i.e. ":pre[vious]") and everything else.
Does that imply that VIM has no :pre[serve] command?
Do you just loose your work if the system goes down unexpectedly?
HansM
From darren@hunan.rastek.com (Darren Hiebert)
Subject: Re: Editing multiple files in vi
Date: Fri, 2 Jul 1993 15:15:41 GMT
In article <2117k5$3el@wsinti07.info.win.tue.nl> hansm@wsinti07.info.win.tue.nl (Hans Mulder) writes:
>In <C9Fw3H.7nn@hunan.rastek.com> darren@hunan.rastek.com (Darren Hiebert) writes:
[ I wrote, about vi: ]
>
>>>Unfortunately, there's no :prev .
>
>>I recommend getting VIM. It's the best vi clone (superset) going.
>>It has a "previous" command (i.e. ":pre[vious]") and everything else.
>
>Does that imply that VIM has no :pre[serve] command?
>
>Do you just loose your work if the system goes down unexpectedly?
VIM keeps an autoscript file that contains the changes made to a file since
the last save. This autoscript file is updated every 100 keystrokes or
after two seconds of inactivity (both configurable). This allows recovery
using the usual vi-like method of "vim -r filename".
BTW, VIM uses ":N[ext]" (opposite direction as ":n[ext]") or ":pre[vious]"
(two forms of the same command).
--
-----------------------------------------------------------------------------
Darren Hiebert (darren@rastek.com) "Made entirely from recycled materials"
-----------------------------------------------------------------------------
From cmorgan@intel.com (Clark Morgan)
Subject: Re: Editing multiple files in vi
Date: Fri, 2 Jul 1993 18:27:45 GMT
Does vim support the display of multiple windows in the same session,
ala vile and emacs? I.E., can I open two windows -- one editing, say,
j.c and one editing, say, k.c, and then use vim commands to switch
between the two windows/buffers?
BTW, vile supports this feature and I've become addicted to it.
--
Clar

50
comp.editors/nthoccurance Normal file
View File

@ -0,0 +1,50 @@
From hjiwa@gruc19.nor.chevron.com (Jeff Wang)
Subject: Re: nth occurance of a string
Date: 9 Jun 93 17:27:41 GMT
gaspar@angelo.amd.com (Harand Gaspar) writes:
|> How does one find the nth occurance of a string or regualr expression
|> in a file using vi?
Try this keymap :-)
"? v - Find the nth occurrence of the pattern on the current line.
"? Enter pattern to search (can use regular expressions) on a new
"? line, then enter number (>1 but no more than 60 occurrences)
"? followed by \f in command mode to look for the pattern's nth
"? occurrence. nowrapscan must be set. If a mistake was made in
"? the pattern that was requested, u undo to bring back pattern.
map v I@x^[a^M^M/^[:mo---^M"xddf@imz`add`z^["yddma@yk
where ^[ are quoted <Escape> keys and ^M are quoted <Return> keys.
Pressing the mapped key <v> (or whatever you map it to) will find the nth
occurrence of the pattern on the current line. For example, if you want to go
the 30 occurrence of the pattern "Due Date", enter "Due Date" on a new line.
Then, press <3> <0> <v> without pausing. The pattern will be deleted and you
will be brought down to the 30th occurrence of "Due Date", if it exists. If you
press <u> to undo at this point, you will be returned back up to the pattern,
where you may make changes if desired. Note that the counting of the number of
occurrences begins at the point after the pattern is typed, not from the first
line in the file. To find nth occurrence from the start of the file, enter the
pattern on line 1. The keymap has a limit of finding up to the 60th occurrence
of a pattern on the version of vi I am using before it chokes with the error
message "Register too long to fit in memory". Your vi might allow more; if your
vi also has this limit and you need to count more finds (say...the 200th
occurrence), you could first find the 60th and then open up a new line, type the
pattern again on the new line, and execute the keymap again to bring you down to
the 120th occurrence, etc, etc. You must also "set nowrapscan" or else the
keymap will wrap around the end of file and keep counting. If you enter a
number that is greater than the actual number of occurrences, the keymap will
bring you down to the last pattern that it found, but you will see the usual
"Address search hit BOTTOM without matching pattern".
Regular expressions can also be used. If you type "[Th]he /" on a new
line, it will find and count all occurrences of "The" or "the" only if the
word is followed by 3 spaces. If you type \<[Dd]ate\> on the line and then
enter <4><5><v>, it will find the 45th occurrence of "Date" or "date" (only if
it is an entire word), and skip past "dated", "Dates", etc. Basically, any
valid vi search string can be used; the keymap just slaps a "/" in front of it
and executes the find command "n" number of times.
#====}==) #===(==} #====}==) #===(==} {==)===# (=={====# {==)===# (=={====#
>> Jeff Wang Net : hjiwa@gruc19.

66
comp.editors/octal Normal file
View File

@ -0,0 +1,66 @@
From Tom Christiansen <tchrist@convex.COM>
Subject: Re: vi: how does one deal with characters like \331 ?
Reply-To: tchrist@convex.COM (Tom Christiansen)
Date: Thu, 16 Jul 1992 19:25:24 GMT
Corp. The opinions expressed are those of the user and
not necessarily those of CONVEX.
>From the keyboard of gordon@osiris.cso.uiuc.edu (John Gordon):
:In vi, how do you enter a character like \331 into a search pattern?
Under most implementations, you don't, since most versions can't
edit 8-bit files anyway.
--tom
--
Tom Christiansen tchrist@convex.com convex!tchrist
Emacs is a fine operating system, but I still prefer UNIX. -me
From gordon@osiris.cso.uiuc.edu (John Gordon)
Subject: vi: how does one deal with characters like \331 ?
Date: 16 Jul 92 18:44:07 GMT
In vi, how do you enter a character like \331 into a search
pattern?
---
John Gordon My incredibly witty saying has been
gordon@osiris.cso.uiuc.edu Politically Corrected into oblivion.
From wyle@synopsys.com (Mitch Wyle)
Subject: Re: vi: how does one deal with characters like \331 ?
Date: 20 Jul 92 17:11:52 GMT
In <1992Jul16.192524.29230@news.eng.convex.com>
tchrist@convex.COM (Tom Christiansen) writes:
>:In vi, how do you enter a character like \331 into a search pattern?
>
>Under most implementations, you don't, since most versions can't
>edit 8-bit files anyway.
> Tom Christiansen tchrist@convex.com convex!tchrist
:verssion
Version SVR3.1
(in sun-os) does edit 8-bit chars,
Mitch Wyle (415) 694 4076 (work)
Synopsys Inc (408) 255 1848 (home)
700 E. Middlefield Rd. (415) 965 8637 (fax)
Mountain View, CA 94043-4033 (800) 843 5669 x4076 (VoiceMail)
From gordon@osiris (John Gordon)
Subject: how to deal with octal characters in vi?
Date: Sat, 11 Jul 1992 04:45:30 GMT
Recently, I had cause to edit a file using vi, and the file had a
few upper-ASCII characters in it. They show up as octal characters, i.e.
\056, \310

124
comp.editors/paragraph Normal file
View File

@ -0,0 +1,124 @@
From kencham@myria.cs.umn.edu (Deepak "Kerd")
Subject: Could someone explain what "paragraphs=IPLPPPQPP LIpplpipnpb" means ??
Date: 8 Jun 92 00:32:55 GMT
Article-I.D.: myria.kencham.707963575
Hi VI-GURUs,
Just wondering what that setting means ..... Could you help me ?
Deepak
--------------------------------------------------------------------------------
Sherlock Holmes observed that ".. After you have eliminated the impossible, only
the possible, however improbable, remains..". I, however, do not like to elimin-
ate the impossible. And so I believe, Holmes and Watson were gays.
--------------------------------------------------------------------------------
Email: kencham@{cs,centi.cs}.umn.edu Department of Gopher Science
Voicemail:(res)(612)339-8397 University of Minnesota
(off)(612)626-7524 Minneapolis, MN 55455, USA
--------------------------------------------------------------------------------
--
--------------------------------------------------------------------------------
J.S.S.Holmes observed that ".. After you have eliminated the impossible, only
the possible, however improbable, remains..". I, however, do not like to elimin-
ate the impossible. And so I believe, Holmes and Watson were gays.
From nh@cbnewsg.cb.att.com (nicholas.hounsome)
Subject: Re: Could someone explain what "paragraphs=IPLPPPQPP LIpplpipnpb" means ??
Date: Tue, 9 Jun 1992 07:25:00 GMT
>From article <kencham.707963575@myria>, by kencham@myria.cs.umn.edu (Deepak "Kerd"):
> Hi VI-GURUs,
>
> Just wondering what that setting means ..... Could you help me ?
>
> Deepak
> --------------------------------------------------------------------------------
> Sherlock Holmes observed that ".. After you have eliminated the impossible, only
> the possible, however improbable, remains..". I, however, do not like to elimin-
> ate the impossible. And so I believe, Holmes and Watson were gays.
> --------------------------------------------------------------------------------
> Email: kencham@{cs,centi.cs}.umn.edu Department of Gopher Science
> Voicemail:(res)(612)339-8397 University of Minnesota
> (off)(612)626-7524 Minneapolis, MN 55455, USA
> --------------------------------------------------------------------------------
> --
> --------------------------------------------------------------------------------
> J.S.S.Holmes observed that ".. After you have eliminated the impossible, only
> the possible, however improbable, remains..". I, however, do not like to elimin-
> ate the impossible. And so I believe, Holmes and Watson were gays.
they are (n|t)roff macros which follow a point '.' at the beginning of a line
as in:
.IP some stuff
If you are not using this they are not much use. I am occasionaly forced to
write uniplex documents which use .PA for page breaks and I sometimes set
up paragraphs for this because uniplex is so horrible but reasonably easy
to hack in vi. Of course for code use the paragraph commands '{' and '}'
also recognise curly barckets at the beginning of a line which makes it
easy to go from function to function. It realy ought to be generalised
to a sequence of space separated stuff which might start a line.
Nick Hounsome
From eric@ils.nwu.edu (Eric Goldstein)
Subject: Paragraphs and vi
Date: Sun, 4 Oct 1992 02:16:32 GMT
Hi!
I'm looking for a way to automatically format paragraphs using vi.
I've been using vi for years, (and I love it, and I've resisted
switching to Emacs), and all this time I've just used "J" and the
return keys. But I really wish there was less annoying way to do it.
(At least on my system, setting the wrapmargin to greater than zero
doesn't influence the behavior of the "J" command.)
If it isn't clear what I mean by "formatting paragraphs", here is
an example:
------------------------------------------------------------------
This is a sample sentence.
This is sample sentence number two, which is longer than the others.
This is sample sentence number three.
This is sample sentence number four.
|
| I want a way to automatically convert the above four lines
| of text into a nicely formated paragraph.
V
This is a sample sentence. This is sample sentence number two, which
is longer than the others. This is sample sentence number three. This
is sample sentence number four.
---------------------------------------------------------------------
I would greatly appreciate any help on this!
-- Eric (eric@ils.nwu.edu)
--
From imc@comlab.ox.ac.uk (Ian Collier)
Subject: Re: Paragraphs and vi
Date: 5 Oct 92 11:49:07 GMT
X-Local-Date: Monday, 5th October 1992 at 12:48pm BST
In article <1992Oct5.075455.27645@cbfsb.cb.att.com>, nh@cbnewsg.cb.att.com (nicholas.hounsome) wrote:
>From article <1992Oct4.050951.2469@ils.nwu.edu>, by eric@ils.nwu.edu (Eric Goldstein):
>> ------------------------------------------------------------------
>> stty: TCGETS: Operation not supported on socket
>> This is a sample sentence. This is sample sentence number two, which
>> is longer than the others. This is sample sentence

90
comp.editors/parawrap Normal file
View File

@ -0,0 +1,90 @@
From larryhsu@mtl.mit.edu (Lawrence Hsu)
Subject: Paragraph wrapping in VI
Date: Fri, 29 May 1992 19:41:54 GMT
Is there a relatively simple way of wrapping paragraphs in vi?
What I often want to do is wrap several short lines into fewer longer lines
without having to "J" them all together and then insert carriage returns.
Many thanks,
Larry Hsu
larryhsu@mtl.mit.edu
From hashmi@cse.uta.edu (Atiqullah Hashmi)
Subject: Re: Paragraph wrapping in VI
Date: Sat, 30 May 1992 23:41:07 GMT
In article <1992May29.194154.18364@athena.mit.edu> larryhsu@mtl.mit.edu (Lawrence Hsu) writes:
>Is there a relatively simple way of wrapping paragraphs in vi?
>What I often want to do is wrap several short lines into fewer longer lines
>without having to "J" them all together and then insert carriage returns.
Go to the first line of a paragraph and break that line where you
want the right margin. Then go to the starting of the first line(col. 1)
of that paragraph and do these things:
press a '!'
press a ']'
Here your cursor will go to the bottom of screen and '!' will appear, then
type 'fmt'
Note: Don't type any quotes as I have shown above, I used them for
clarity. Also, this method works for one paragraph only, so you will
have to do for each paragraph if you have more than one.
Hope it helps
hashmi
--
---------------------------------
Atiqullah Hashmi
UTA (Univ. of Texas at Arlington)
hashmi@cse.uta.edu
From dylan@ibmpcug.co.uk (Matthew Farwell)
Subject: Re: Paragraph wrapping in VI
Date: Sun, 31 May 1992 14:22:12 GMT
In article <1992May30.234107.8048@cse.uta.edu> hashmi@cse.uta.edu (Atiqullah Hashmi) writes:
>In article <1992May29.194154.18364@athena.mit.edu> larryhsu@mtl.mit.edu (Lawrence Hsu) writes:
>>Is there a relatively simple way of wrapping paragraphs in vi?
>>What I often want to do is wrap several short lines into fewer longer lines
>>without having to "J" them all together and then insert carriage returns.
>Go to the first line of a paragraph and break that line where you
>want the right margin. Then go to the starting of the first line(col. 1)
>of that paragraph and do these things:
>
>press a '!'
>press a ']'
^
> Here your cursor will go to the bottom of screen and '!' will appear, then
>type 'fmt'
Of course, he means '}' here.
Dylan.
--
It is no coincidence that in no known language does the phrase 'As
pretty as an Airport' appear -- Douglas Adams
From agc@bnr.ca (Alan Carter)
Subject: Re: Paragraph wrapping in VI
Date: 2 Jun 92 10:31:38 GMT
In article <1992May29.194154.18364@athena.mit.edu>, larryhsu@mtl.mit.edu (Lawrence Hsu) writes:
|> Is there a relatively simple way of wrapping paragraphs in vi?
|> What I often want to do is wrap several short lines into fewer longer lines
|> without having to "J" them all together and then insert carriage returns.
The vi command you need is
:1,$!adjust
The ! pumps the specified lines out to the standard in of the chosen program,
catches the standard out and replac

228
comp.editors/readin Normal file
View File

@ -0,0 +1,228 @@
From jayers@hamline.edu (Judi Ayers)
Subject: VI editor questions
Date: 27 May 92 19:57:24 GMT
I have two files and this is what I'd like to accomplish:
While using vi on one file, I would like to read
in specific lines from a second file (I already know what the
line numbers are). Is there a way to do this using :r ? I know
I can write out specific line numbers to a file, and the command
I want seems to be one that is just the opposite. I've tried various
things with no luck and can't find any documentation on it. Any ideas?
I hope this is the right group to ask about a VI question. If not,
I'm sure I'll hear about it. Or better yet, please direct me to the
correct group. Thanx.
Judi Ayers
jayers@hamline.edu
From Tom Christiansen <tchrist@convex.COM>
Subject: Re: VI editor questions
Reply-To: tchrist@convex.COM (Tom Christiansen)
Date: Wed, 27 May 1992 22:12:42 GMT
>From the keyboard of jayers@hamline.edu (Judi Ayers):
<I have two files and this is what I'd like to accomplish:
<While using vi on one file, I would like to read
<in specific lines from a second file (I already know what the
<line numbers are). Is there a way to do this using :r ? I know
<I can write out specific line numbers to a file, and the command
<I want seems to be one that is just the opposite. I've tried various
<things with no luck and can't find any documentation on it. Any ideas?
Try:
:r!sed -n 50,75p file
--tom
From fgg@gemini.tmc.edu (Frank G. Gomez)
Subject: Re: VI editor questions
Date: 27 May 92 22:49:46 GMT
You could try:
:r ! awk 'NR >= start && NR <= end' otherfile
where 'start' is your starting line number from the
other file and 'end' is the ending line number, and
'otherfile' is of course the other file. The '!' puts
the standard output of whatever command follows after
the current line in the file you are editing.
Frank
From P.G.Widdop@bradford.ac.uk (Paul Widdop)
Subject: Re: VI editor questions
Date: 28 May 92 04:02:20 GMT
jayers@hamline.edu (Judi Ayers) writes :
>I have two files and this is what I'd like to accomplish:
>While using vi on one file, I would like to read
>in specific lines from a second file (I already know what the
>line numbers are).
This is probably a bit a of kludge but I suppose you could do the following
vi command (on an empty line where you want to insert the text) ...
:.!awk '{if (NR >= startline && NR <= endline) print $0}' <file2>
where startline and endline are the line numbers in <file2> that you want to
copy between.
No doubt the flames will start to fly now :)
~paul
--
o---------------------------------------\ /-----------------------------------o
| JANET : P.G.Widdop@uk.ac.bradford | " I sometimes wonder if anything |
| Internet : P.G.Widdop@bradford.ac.uk | is really worth the effort " |
| : pwiddop@nyx.cs.du.edu | |
o---------------------------------------/ \-----------------------------------o
If MS-DOS didn't exist, who would UNIX programmers hav to make fun of ??
From felps@dfs.austin.ibm.com (Robert Felps)
Subject: Re: VI editor questions
Date: 27 May 92 12:26:50 GMT
In article <1992May27.225326.18703@tamsun.tamu.edu> pck0276@tamsun.tamu.edu (Philip Kizer) writes:
>In article <1992May27.195724.7568@uc.msc.edu> you write:
>>I have two files and this is what I'd like to accomplish:
>>While using vi on one file, I would like to read
>>in specific lines from a second file (I already know what the
>>line numbers are). Is there a way to do this using :r ? I know
>>I can write out specific line numbers to a file, and the command
>>I want seems to be one that is just the opposite. I've tried various
>>things with no luck and can't find any documentation on it. Any ideas?
>
>Well, the first thing that came to mind was to use a combination of head
>and tail. (Thank you for asking, I've wanted to work this out for a while,
>but hadn't the motivation :)
>
>This will work to read lines 63 through 77 from file <file>:
>:r !head -77 <file> | tail -15
Well, I would either try,
vi file1 # edit file1 with vi
/locate_place_to_add_lines # locate place for add. lines in file1
:r !sed -n 63,77p file2 # read lines 63-77 of file2 into file1
ZZ # save and exit vi
or try:
vi file1 file2 # edit both files with vi
/locate_place_to_add_lines # locate place for add. lines in file1
:n # goto (edit) next file (file2)
63G # goto line 63 in file2
"q15yy # yank 15 lines to the q register/buffer
:e# # edit the alternate file (file1)
"qp # put the contents of register q in file1
ZZ # save and exit vi
or try:
vi file1 # edit file1 with vi
/locate_place_to_add_lines # locate place for add. lines in file1
:e file2 # edit alternate file (file2)
63G # goto line 63 in file2
"q15yy # yank 15 lines to the q register/buffer
:e# # edit the alternate file (file1)
"qp # put the contents of register q in file1
ZZ # save and exit vi
Hope it helps,
Robert
felps@cactus.org
From brandy@tramp.Colorado.EDU (BRANDAUER CARL M)
Subject: Re: VI editor questions
Date: Fri, 29 May 1992 15:14:58 GMT
ctwomey@ccvax.ucd.ie writes:
>I have two files and this is what I'd like to accomplish:
>While using vi on one file, I would like to read
>in specific lines from a second file (I already know what the
>line numbers are). Is there a way to do this using :r ?
Yes, indeed.
:r !unix_command
will read the output of the command into the vi buffer. For your
particular application the following will work:
:r !sed -n x,yp source_file
where x and y are the first and last line number, respectively, that you
want to insert. Note that with proper quoting you could use regular
expressions in place of x or y or both.
Cheers - Carl
From weimer@garden.NoSubdomain.NoDomain (Gary Weimer (253-7796))
Subject: Re: VI editor questions
Reply-To: weimer@ssd.kodak.com
Date: Fri, 29 May 92 15:43:32 GMT
In article <1992May28.091554.49042@ccvax.ucd.ie>, ctwomey@ccvax.ucd.ie writes:
|>
|> I have two files and this is what I'd like to accomplish:
|> While using vi on one file, I would like to read
|> in specific lines from a second file (I already know what the
|> line numbers are). Is there a way to do this using :r ? I know
|> I can write out specific line numbers to a file, and the command
|> I want seems to be one that is just the opposite. I've tried various
|> things with no luck and can't find any documentation on it. Any ideas?
There are 2 ways I can think of:
The easy way to EXPLAIN:
:r! tail +<number_of_first_line> <file_to_read> | head -<number_of_lines>
OR
:r! sed -n '<number_of_first_line>,<number_of_last_line>p' <file_to_read>
The easy way to DO (You don't need exact line numbers--see NOTES):
:e <file_to_read> # edit second file
:<number_of_first_line> # go to first line to copy
<number_of_lines>"xY # yank lines into buffer x
:e# # go back to first file
"xp # put lines after current line
NOTES:
- may have to save changes to first file before editing second file
- you can get to the first line using searches, cursor moves, etc.
- Yank command could be "xy<range> to get a word, sentence,
paragrah, etc.
- a short-cut for :e# is ^6 (ctrl-6)
|> I hope this is the right group to ask about a VI question.
It's the only group I can think of...
--
weimer@ssd.kodak.com ( Gary Weimer )
From bill@Celestial.COM (Bill Campbell)
Subject: Re: VI editor questions
Date: 31 May 92 02:57:18 GMT
In article <1992May27.195724.7568@uc.msc.edu>, jayers@hamline.edu (Judi Ayers) writes:
I have two files and this is what I'd like to accomplish:
While using vi on one file, I would like to re

288
comp.editors/regexp Normal file
View File

@ -0,0 +1,288 @@
From sjreeves@eng.auburn.edu (Stan Reeves)
Subject: Regular Expression Question
Date: 12 Aug 92 12:54:06 GMT
I need to construct a regular expression that locates all words without
an "@". I've exhausted all my own ideas and was wondering if I could
draw on the expertise of this group.
--
Stan Reeves
Auburn University, Department of Electrical Engineering, Auburn, AL 36849
INTERNET: sjreeves@eng.auburn.edu
From lwv26@cas.org (Larry W. Virden)
Subject: Re: Regular Expression Question
Reply-To: lvirden@cas.org (Larry W. Virden)
Date: Thu, 13 Aug 1992 11:52:27 GMT
In article <sjreeves.920812075405@eng.auburn.edu> sjreeves@eng.auburn.edu (Stan Reeves) writes:
:
:I need to construct a regular expression that locates all words without
:an "@". I've exhausted all my own ideas and was wondering if I could
:draw on the expertise of this group.
Easy I thought, and I typed vi /etc/motd to play.
First, I tried:
/\<[^@]+\>
which is the most obvious thing. And I got an error. Oh, vi doesn't appear
to recognize +. Sigh. Well, let's try the next most obvious:
/\<[^@]*\>
That will do it, right? Nah. The problem here is that the * eats everything
up to the first @ in the line and treats it all as a string.
/\<[^.,<>!@#$%^&*()_-+=|\\{}:;"'~` ]*\>
is close - there may be a few more things that I missed in there, and
there may be a need to quote a couple of those characters. I gave up
after finding a subset of the above that worked enough to show me the
theory is right...
--
Larry W. Virden UUCP: osu-cis!chemabs!lvirden
Same Mbox: BITNET: lvirden@cas INET: lvirden@cas.org
Personal: 674 Falls Place, Reynoldsburg, OH 43068-1614
America Online: lvirden@aol.com
From navarra@casbah.acns.nwu.edu (John Navarra)
Subject: Deleting text above and below PATTERN recursively
Date: Sat, 11 Jul 1992 00:04:36 GMT
I want to do some recursive file manipulations using either vi
or ed under the following scenario:
I have a file the contains a certain pattern which occurs at the
beginning of a line multiple times in a file. I want to delete 5 lines
above that pattern and 6 lines below that pattern for each occurance of
PATTERN in the file. I need some help writing a recursive routine to do
this. I started with the following ed script to do the first occurance:
/^PATTERN #search for first occurance of PATTERN at begin of line
-5n #go up five lines
.,+4d #delete from current line down 4 lines
.+1p #print current line (skip the line matching PATTERN)
.,+5d #delete from current line down 5 lines
w #write it.
q #quit editing.
Now I need some way to recursively search for PATTERN and give the
neccessary 'q' for ed to complete the operations when no more PATTERNS
have been found.
I would love to see a solution in vi as well.
Any ideas?
here is an idea of what the file would look like:
1
2
3 5 lines to be deleted
4
5
PATTERN TO MATCH
1
2
3
4 6 lines to be deleted
5
6
more text of file which does not need to be deleted
1
2
3
4
5
PATTERN TO MATCH
1
2
3
4
5
6
Thanx for any help,
-tms
From hansm@cs.kun.nl (Hans Mulder)
Subject: Re: Deleting text above and below PATTERN recursively
Date: Sat, 11 Jul 1992 03:39:36 GMT
In <1992Jul11.000436.15556@news.acns.nwu.edu> navarra@casbah.acns.nwu.edu (John Navarra) writes:
> I want to do some recursive file manipulations using either vi
>or ed under the following scenario:
Is there any particular reason you insist on doing it recursively?
> I have a file the contains a certain pattern which occurs at the
>beginning of a line multiple times in a file. I want to delete 5 lines
>above that pattern and 6 lines below that pattern for each occurance of
>PATTERN in the file. I need some help writing a recursive routine to do
>this. I started with the following ed script to do the first occurance:
>/^PATTERN #search for first occurance of PATTERN at begin of line
>-5n #go up five lines
>.,+4d #delete from current line down 4 lines
>.+1p #print current line (skip the line matching PATTERN)
Which is it? Do you want to print the line containing PATTERN, or do
you want to skip it?
>.,+5d #delete from current line down 5 lines
In the paragraph above you said 6.
>w #write it.
>q #quit editing.
If I can assume that there are enough line above the first and below the
last occurance of PATTERN and that you wanted to skip the matching lines,
and that you meant 6 rather than 5, a vi/ex command to do it would be:
:g/^PATTERN/-5,-1d|+1,+6d
If on the other hand there might be occurances of PATTERN in the first or the
last 5 lines, and you do want those matching lines printed, you'd do:
:6,$-6g/^PATTERN/-5,-1d|p|+1,+6d
Or, if you insist on minimizing the number of keystrokes:
:6,$-6g/^PATTERN/-5,-dp|+,+6d
I'm afraid you can't do it in a single command in ed, you'll have to use two:
g/^PATTERN/-5,-d
g/^PATTERN/+,+6d
Add a 'p' to the first of these lines if you want to print the matching line.
Stick '6,$-6' in front if occurances of PATTERN near the extremes of the file
are a problem.
> I would love to see a solution in vi as well.
If you insist on doing it recursively and using true vi mode commands:
:write " just in case... :-}
:set nowrapscan report=7 " so vi won't say "5 lines deleted"
:map K n5k5ddj6ddK+ " the + stops vi from saying "No tail recursion"
/^PATTERN/
1GK
:unmap K " too dangerous to keep it around
:set wrapscan report=5
When you've typed the 1GK bit, vi will move around a lot and eventually
report: "Address search hit BOTTOM without matching pattern". Ignore that.
--
Hope this helps,
Hans Mulder hansm@cs.kun.nl
From dattier@ddsw1.mcs.com (David W. Tamkin)
Subject: Re: Deleting text above and below PATTERN recursively
Date: Sun, 12 Jul 1992 02:39:31 GMT
the poster and does not represent MCSNet or the system owners.
navarra@casbah.acns.nwu.edu (John Navarra) wrote in
<1992Jul11.205053.29328@news.acns.nwu.edu>:
| I tried to put this in my .exrc file with the line:
|
| :map ^Tp :g/^PATTERN/-5,-1d|+1,+6d
|
| and I got the error "No lines in buffer" when starting up vi. A ^Tp
| only printed: :g/^PATTERN/-5,-1d
|
| what happened?
Just as the pipe is a separator in an ex command, it is a separator in .exrc.
You told your .exrc to do TWO things with that line:
1. to :map ^Tp :g/^PATTERN/-5,-1d
and
2. to +1,+6d
Accordingly it mapped ^Tp as you told it and tried to delete the six lines
below the current one, but there were no lines in the buffer when vi sourced
.exrc, so it couldn't do the second part.
The only way to include pipes in mappings is to precede them with a hard ^V;
that is, when you prepare your .exrc you have to type ctrl-V twice to get a
ctrl-V to stay in the file.
For a mapping like this one, which gets rescanned, one hard ^V should be
enough, since on the second scan you *want* the pipe to be interpreted as a
command separator. Sometimes it takes three, five, or even seven hard ^V's
in a mapping in .exrc to get some problem characters like a pipe or the ^M
that will eventually become a ^J sufficiently quoted.
By the way, since you are mapping an ex command, you'll need a newline at the
end, so you have to put ^M (typed as ctrl-V ctrl-M) [or ^V^M (typed as three
ctrl-V's and a ctrl-M) or even ^V^V^V^M] on the end of that mapping, or when
you use it, the cursor will sit at the end of the command window at the
bottom of the vi screen and the commands in the mapping won't execute until
you send NL manually.
David W. Tamkin Box 59297 Northtown Station, Illinois 60659-0297
dattier@ddsw1.mcs.com CompuServe: 73720,1570 MCI Mail: 426-1818
From navarra@casbah.acns.nwu.edu (John Navarra)
Subject: Re: Deleting text above and below PATTERN recursively
Date: Sat, 11 Jul 1992 20:50:53 GMT
In article <1992Jul11.033936.10152@sci.kun.nl> hansm@cs.kun.nl (Hans Mulder) writes:
>In <1992Jul11.000436.15556@news.acns.nwu.edu> navarra@casbah.acns.nwu.edu (John Navarra) writes:
>
>>/^PATTERN #search for first occurance of PATTERN at begin of line
>>-5n #go up five lines
>>.,+4d #delete from current line down 4 lines
>>.+1p #print current line (skip the line matching PATTERN)
>
>Which is it? Do you want to print the line containing PATTERN, or do
>you want to skip it?
This will skip the line by printing it.
>
>>.,+5d #delete from current line down 5 lines
>
>In the paragraph above you said 6.
The way ed does this is by deleting the current line AND 5 more
additional lines ==6 lines. That is what I wanted to do. If you notice
the line '.,+4d' , this does the same thing and deletes 5 lines above
the pattern.
>
>If I can assume that there are enough line above the first and below the
>last occurance of PATTERN and that you wanted to skip the matching lines,
>and that you meant 6 rather than 5, a vi/ex command to do it would be:
>
>:g/^PATTERN/-5,-1d|+1,+6d
>
Yes, this is perfect. I didn't know you could do this in vi. I
do not need any recursion if a global search and replace option is
available. I didn't know about the '|' in vi.
btw,
I tried to put this in my .exrc file with the line:
:map ^Tp :g/^PATTERN/-5,-1d|+1,+6d
and I got the error "No lines in buffer" when starting up vi. A ^Tp
only

104
comp.editors/repeatcmd Normal file
View File

@ -0,0 +1,104 @@
From watts@cs.scarolina.edu (Chris Watts)
Subject: VI: Repeating a command.
Date: 20 Jul 93 16:00:04 GMT
Please tell there is a way in VI to do this! Let's say I want to move
lines 30 - 50 back 3 spaces. How would I do this. Or another question
is if I perform an operation on one line, how can I perform the same
operation on multiple lines. Thanks.
Chris Watts
-------------------------------------------------------------------------------
watts@cs.scarolina.edu
From lange@obelix.pcs.dec.com (Ralf Lange Digital-PCS GmbH)
Subject: Re: VI: Repeating a command.
Reply-To: lange@obelix.pcs.dec.com (Ralf Lange Digital-PCS GmbH)
Date: Wed, 21 Jul 1993 06:08:36 GMT
move back lines 30 - 50 3 spaces:
:30,50!expand
:30,50s/^ //
the first command changes all tab characters to spaces.
The second command kills 3 spaces from the beginning
of every line. If your tab is set to three there is an
easier way:
type '30G' in command mode to goto line 30 and then '21<<'
to shift the current and the next 20 lines to the left.
An alternative would be:
:20,30<<
to perform the same operation on multiple lines:
this depends on what you did to change the first line.
If you used the substitute command, just give another
line range to perform the same substitution to other lines.
EXAMPLE:
:s/.*/\L&/
changes the current line to lower case characters.
Then
:20,50s
:'a,.s
:/Hi there/,$s
will do the same substitution from
line 20 to line 50
mark 'a' up to the current line
the next occurence of 'Hi there' to the end of the file.
From hansm@wsinti06.info.win.tue.nl (Hans Mulder)
Subject: Re: VI: Repeating a command.
Date: 21 Jul 1993 14:29:47 +0200
In <watts.743184004@walnut.cs.scarolina.edu> watts@cs.scarolina.edu (Chris Watts) writes:
>Please tell there is a way in VI to do this! Let's say I want to move
>lines 30 - 50 back 3 spaces. How would I do this.
If those lines all begin with spaces (not tabs), then
:30,50s/^ /
would do the trick. If you've :set shiftwidth=3, then
:30,50<
would work even if there are tabs. In practice, you'd be more likely
to use something like 21<< or <% or <50G or <]] or <`x or whatever.
>Or another question
>is if I perform an operation on one line, how can I perform the same
>operation on multiple lines.
If it's a single vi mode command, then typing a period (.) performs the
same operation on the current cursor position.
If it's a :s/// command, then ampersand (&) does the same substitution
on the current line. There's also :30,50& to do the substitution on
those lines (and there's :30,50&g if you want to change all occurrences
of your pattern, rather than only the leftmost one).
There's also :g/pattern/ex-mode-commands to do some ex mode commands on
selected lines.
Or you could create a macro, by typing :map v vi-mode-commands.
It depends.
HansM
From carlj@cyclone.bt.co.uk (Carl Johnson)
Subject: Re: VI: Repeating a command.
Date: 21 Jul 1993 08:19:22 GMT
Reply-To: carlj@cyclone.bt.co.uk
Chris Watts (watts@cs.scarolina.edu) wrote:
: Please tell there is a way in VI to do th

21
comp.editors/replace Normal file
View File

@ -0,0 +1,21 @@
From dattier@genesis.MCS.COM (DWT)
Subject: Re: Replacement prompting in vi?
Date: 7 Jun 1993 21:47:27 -0500
Reply-To: dattier@genesis.mcs.com (DWT)
thanasis@ucsb.edu (Athanassios S. Poulakidas) wrote in <8940@ucsbcsl.ucsb.edu>:
| I'd like to have interactive search&replace in vi, i.e., when I want to
| substitute string1 with string2 globally, for each [occurrence] of string1
| in the file, vi should ask me if the substitution should be performed.
|
| Is there a macro that efficiently does this?
It's already built in. Add the c flag to the substitution command:
:range s/target/replacement/gc
David W. Tamkin Box 59297 Northtown Station, Illinois 60659-0297
dattier@genesis.mcs.com CompuServe: 73720,1570 MCI Mail: 426-1818

94
comp.editors/sandr Normal file
View File

@ -0,0 +1,94 @@
From: dylan@ibmpcug.co.uk (Matthew Farwell)
Newsgroups: comp.editors
Subject: vi search and replace (LONG)
Keywords: vi replace
Date: 16 Sep 91 18:48:17 GMT
Reply-To: dylan@ibmpcug.CO.UK (Matthew Farwell)
Organization: The IBM PC User Group, UK.
In article <stanley.685027807@techunix.technion.ac.il> stanley@techunix.technion.ac.il (stan c) writes:
>can anyone tell me how to correctly use the replace
>feature in vi?
>I have a (rather long) file which has a whole bunch of control
>characters at the end of each line (cat -v shows it as ^M)
>How can I get rid of them?
Ok, the quick answer is:
:1,$s/^M//g
where ^M is ctrl-V ctrl-M.
The replace command has a format like this:
:<range of lines>s/<old text>/<new text>/<qualifiers>
<range of lines> can be specified in a number of ways. You can give the
numbers, ie 1,4 does lines 1 2 3 4 ($ is last line), you can say from
mark 'm' to mark 'n', ie 'm,'n, or you can give a search command, ie
/^$/,/^fredleg/ does from the next blank line to the next line matching
^fredleg. Or you can have any combination of those. You can even
search backwards using ? instead of / if you want to.
so:
:1,$ == every line
:/^$/,$ == lines from the first blank line to the end
:'m,/^$/ == lines from mark m to the first blank line after the
current cursor position
:1,?^$? == line 1 to the previous blank line.
but be careful when using the searching commands when defining a range
of lines. If you have wrapscan set it can sometimes have interesting
effects, if, say, you don't hit a match before the end of the file. I
find that using searches that aren't certain to hit the right place is a
recipe for disaster. I just prefer to go to the line, mark it and then
go back and use :'m,. or whatever.
<old text> is just a normal regular expression [*]
<new text> is the replacement text. The simple form is:
:1,$s/dylan/matthew/
or
:1,$s/dyl*an/matthew/
You can also use the \L \l \U \u \E and \e qualifiers. These convert
text to lower case or to upper case. The lower case versions of these
only work on the next letter. ie if you want to capitalize the 'd'
every occurence of the word 'dylan' in your text, then you can use
:1,$s/dylan/\u&/ (& means all matched text, in this case 'dylan')
If, however you want to capitalise the whole word, then you use \U. If
you want the entire matched string capitalised, then just using \U is
sufficient. If, however, you want to capitalise only parts of the
string, then you can use \e[**] to terminate the changes. ie
:1,$s/\(dyl\)\(an\)/\U\1\e\2/ (\1 and \2 are equivalent to whatever
the first and second \( \) sequences
matched, in this case \1 == 'dyl' and \2
== 'an')
changes all occurences of dylan to DYLan.
Now, the above statements are not strictly true. By default, vi only
susbstitutes the first match on a line, so for instance only the first
dylan in the first line of my .sig would get changed. If you want to do
*all* occurences, then you must add a 'g' qualifier to the end, ie
:1,$s/dylan/matthew/g
The other qualifiers are 'c' and 'p'. 'c' asks for confirmation before
making the change. 'p' prints the matched strings after any replacement
has occured.
Hope this helps.
Dylan.
[*] I haven't got time right now to go into the depths of regular
expressions. Maybe some other time.
[**] As far as I can see, \e and \E have exactly the same effect and are
interchangeable. I'm willing to be corrected though.
--
dylan@ibmpcug.co.uk || ...!uunet!ukc!ibmpcug!dylan
C makes it easy for you to shoot yourself in the foot. C++ makes that
harder, but when you do, it blows away your whole leg - Bjarne Stroustrup

186
comp.editors/spellcheck Normal file
View File

@ -0,0 +1,186 @@
From krisk@ux1.cso.uiuc.edu (Kris Klindworth)
Subject: Re: Is there a spellchecker for VI?
Date: Thu, 27 Aug 1992 15:49:15 GMT
olsonkk@ucsu.Colorado.EDU (OLSON KIRK) writes:
>Hi all... I was wondering if anyone knew if a spellchecker for VI exists
>and or is available? Has anyone ever heard of such a thing?
>Thanks!
>Kirk
>--
>Kirk Olson
>olsonkk@ucsu.colorado.edu
>olsonkir@luther.uni.edu
If you're on a unix machine, you can pipe the lines to be
checked through unix spell.
Ex.
:%!spell
However, this must be undone immediately or you'll lose your
original text. An alternative way to do this is to save the file
and then run spell on it, reading the output into your current text file.
Ex.
:w!
:0r !spell %
This will put the misspelled words at the top of the file.
WHAT I DO:
I use the following key mappings in my .exrc file to approximate
the word processor behavior of
automatically moving the cursor from one misspelled word to the next.
map S :w!:0r !spell %:1,s/^/\//1G
map F "kyy@k
Then a typical sequents is to hit S to run the spell checker, and load
the errors into the beginning of the file, hit F to load the word
into the find buffer, hit n to move on to the next occurrence of the word,
and dd when the cursor comes back to the first line of the file.
From siffert@spot.Colorado.EDU (Thunder-Thumbs)
Subject: Spell-check program needed for vi.
Date: Sat, 3 Jul 1993 20:28:53 GMT
Is there any way, using vi (or a clone), I can put my cursor on
a word, hit a control-key sequence, and it will check the spelling
of that word, prompt me for a correct spelling, and correct it if
I so desire?
I basically want the same functionality as ispell, but when I try
it with ispell, it always assumes the word is a file name and
buggers out on me. I haven't found a working flag.
emacs has a M-x spell-word function, but I want it in vi. Any
ideas?
Curt
From jansteen@cwi.nl (Jan van der Steen)
Subject: Re: Spell-check program needed for vi.
Date: 6 Jul 93 09:07:45 GMT
siffert@spot.Colorado.EDU (Thunder-Thumbs) writes:
>Is there any way, using vi (or a clone), I can put my cursor on
>a word, hit a control-key sequence, and it will check the spelling
>of that word, prompt me for a correct spelling, and correct it if
>I so desire?
Try "spet", and a keymapping like:
map q !!spet -v -t3^M
This will spell the current line in verbose mode while ignoring
words with less than three characters in them.
Example:
Let's say you wroote this and hit "q"
^^^^^^
The program spet is available from:
ftp : sun4nl.nluug.nl
dir : pub/textproc/txttools
file: spet-1.2.tar.Z
Jan van der Steen
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Jan van der Steen jansteen@cwi.nl
Centre for Mathematics and Computer Science (CWI)
Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
From msc@ssigate.ssinc.com (Michael S. Cross)
Subject: Re: Spell-check program needed for vi.
Date: Tue, 20 Jul 1993 12:32:04 GMT
siffert@spot.Colorado.EDU (Thunder-Thumbs) writes:
>Is there any way, using vi (or a clone), I can put my cursor on
>a word, hit a control-key sequence, and it will check the spelling
>of that word, prompt me for a correct spelling, and correct it if
>I so desire?
I don't know of any.
>I basically want the same functionality as ispell, but when I try
>it with ispell, it always assumes the word is a file name and
>buggers out on me. I haven't found a working flag.
vi is a text editor, not a word processor. Why don't you just finish
the "document" while the thoughts are still flowing, and run it through
ispell when you are through. ispell will *automaticly* replace the
misspelled words with your word of choice.
Of course this doesn't always work so well with email or netnews postings.
Hope it helps (tm).
Mike
--
Michael S. Cross Work: msc%ssigate.UUCP@tellab5.tellabs.com 708-505-4508
Home: 73750.1363@CompuServe.com (but not exactly *proud* of it)
Systems and Synchronous Inc., 900 E. Diehl Rd, Suite 110, Naperville, IL 60563
__________________________To Live is to risk Dying____________________________
From ray@Celestial.COM (Ray Jones)
Subject: Re: Spell-check program needed for vi.
Date: Thu, 22 Jul 1993 18:55:29 GMT
In <1993Jul20.123204.8641@ssigate.ssinc.com> msc@ssigate.ssinc.com (Michael S. Cross) writes:
> siffert@spot.Colorado.EDU (Thunder-Thumbs) writes:
>>Is there any way, using vi (or a clone), I can put my cursor on
>>a word, hit a control-key sequence, and it will check the spelling
>>of that word, prompt me for a correct spelling, and correct it if
>>I so desire?
>I don't know of any.
>>I basically want the same functionality as ispell, but when I try
>>it with ispell, it always assumes the word is a file name and
>>buggers out on me. I haven't found a working flag.
There are a couple of ways to do this. If you want to use ispell:
1. write the file to some tmp file
2. run ispell on the tmp file
3. replace the current doc with the correctly spelled tmp file.
that will spell check the whole document.
This can be done with the following map for function key 1
map #1 :w %^M:!ispell %^M^M^[:0r % ^MjdG^M
There are a couple of extra keys in this but it does work.
However, if you want put the cursor on a word, press Control-X and run
ispell on just that word and replace the word with the correct spelling,
then use the following map.
map ^X i^M^[ea^M^[b:.w! /tmp/x^M:!ispell /tmp/x^Mbdw:r /tmp/x^MkkJJJ^M
This map grabs the word, writes it to a file (/tmp/x), runs ispell on that
file, then replaces the word with the new contents of /tmp/x. If you are on
a multi-user system you may want to change the tmp file to something in your
home directory. This will leave tracks (/tmp/x and /tmp/x.bk) but they are
only one word long.
--
INTERNET: ray@Celestial.COM | The probability of one or more
Ray A. Jones; Celestial Software | spelling errors in this missive
8545 S.E. 68th Street | approaches unity. If this bothers you,
Mercer Island, WA 98040;(206) 236-1676 | run it through y

856
comp.editors/startup Normal file
View File

@ -0,0 +1,856 @@
From smr@iti.org (Stephen Riehm)
Subject: esoteric use of vi.. can some1 give me the right syntax??
Date: 17 Jul 92 11:04:41 GMT
Status: RO
I remember that it is possible to put vi/ex initialisation strings into
the top or bottom 5 lines of a text file, and that vi would use those
after reading the .exrc file etc. I want to use this because normally
I have wrapmargin turned on, but in one or two files I want to turn it
off.... so this would be a really neat feature to use. My problem is
that I can't find the reference which describes this feature, and I have
forgotten the format.
from memory it was something like:
--dummy file--
#!/bin/sh
# ex:set wm=0 ai ic
#
# this file will have no wrapping, auto-indenting and ignore case
# set whenever being edited by vi or ex
etc.
If anyone who knows this format could send it to me, I would be most
grateful!
ADVthAnxNCE
-----------------------------------------------------------------
Stephen Riehm smr@pki-nbg.philips.de
not in any way talking on behalf of:
Philips Kommunikations Industrie Phone: +49 911 526 2975
8500 Nuremberg, Germany Fax: +49 911 526 2095
I come from the land down under, where women glow and men chunder
From smr@iti.org (Stephen Riehm)
Subject: esoteric use of vi.. can some1 give me the right syntax??
Date: 17 Jul 92 11:04:41 GMT
Status: RO
I remember that it is possible to put vi/ex initialisation strings into
the top or bottom 5 lines of a text file, and that vi would use those
after reading the .exrc file etc. I want to use this because normally
I have wrapmargin turned on, but in one or two files I want to turn it
off.... so this would be a really neat feature to use. My problem is
that I can't find the reference which describes this feature, and I have
forgotten the format.
from memory it was something like:
--dummy file--
#!/bin/sh
# ex:set wm=0 ai ic
#
# this file will have no wrapping, auto-indenting and ignore case
# set whenever being edited by vi or ex
etc.
If anyone who knows this format could send it to me, I would be most
grateful!
ADVthAnxNCE
-----------------------------------------------------------------
Stephen Riehm smr@pki-nbg.philips.de
not in any way talking on behalf of:
Philips Kommunikations Industrie Phone: +49 911 526 2975
8500 Nuremberg, Germany Fax: +49 911 526 2095
I come from the land down under, where women glow and men chunder
From wja@iclbra.UUCP (Wayne Alston)
Subject: fun bug in vi
Date: 23 May 85 06:52:04 GMT
Date-Received: 25 May 85 03:14:12 GMT
Xpath: stc stc-a
Status: RO
An undocumented feature in vi allows a valid command in the file being
'edited' of the form
...ex:{command}:
or
...vi:{command}:
to be actioned before interactive editing is allowed. However, the bug also
permits the variants ei and vx. The code reads:-
if (beg[-2] != 'e' && beg[-2] != 'v') return;
if (beg[-1] != 'x' && beg[-1] != 'i') return;
in routine checkmodeline().
The bug was discovered by trying to install a user with the initials 'jei' into
/etc/passwd.
Note that the above structure need not be at the beginning of the file.
Try vi'ing a file containing ei:x: .
Wayne Alston
..!reading!iclbra!wja
End of article 104 (of 113)--what next? [npq]
From wcs@ho95b.UUCP (Bill Stewart)
Subject: Re: fun bug in vi
Date: 24 May 85 23:28:34 GMT
Date-Received: 25 May 85 06:04:15 GMT
Status: O
Wayne Allston at ICL had some comments about the "vi-startup-mode" feature:
1) It's undocumented
2) It also accepts ei: and vx: in addition to ex: and vi:
3) It's more of a misfeature than a feature (paraphrased.)
Well, 2) is clearly a bug, and "somebody" ought to fix it. I just checked
the source for version 3.9, and the offending lines of code are still there
in checkmodeline().
However, the startup mode is not undocumented, and it's not a misfeature.
Admittedly, the documentation isn't in the manual page, it's in the file
vax/ex.news in the source directory, but this applies to any features added
since the vi 3.5 version came out. (Hope you've got source! :~)
Whether it's a good feature is somewhat of a religious argument, but I like
it. However, it would be nice to have a modelines/nomodelines option that
you could set in $EXINIT, to make it safer to edit important files, or other
files where the magic sequences might occur.
--
Bill Stewart 1-201-949-0705
AT&T Bell Labs, Room 4K-435, Holmdel NJ
{ihnp4,allegra,cbosgd,vax135}!ho95c!wcs
End of article 105 (of 113)--what next? [npq]
From mark@cbosgd.UUCP (Mark Horton)
Subject: Re: fun bug in vi
Date: 25 May 85 05:13:59 GMT
Date-Received: 25 May 85 12:43:54 GMT
Status: O
This problem is well known - it came out about a year ago.
It has been fixed in vi 3.10. The syntax is now something
that's unlikely to show up by accident in text files, and
very few commands are allowed in a mode line. There
are explicit checks to prevent ! commands, too.
3.10 will probably first be released in System V Release 3.
Mark
End of article 106 (of 113)--what next? [npq]
From guy@sun.uucp (Guy Harris)
Subject: Re: fun bug in vi
Date: 25 May 85 19:27:22 GMT
Date-Received: 27 May 85 01:30:58 GMT
Status: O
> An undocumented feature in vi allows a valid command in the file being
> 'edited' of the form
>
> ...ex:{command}:
> or
> ...vi:{command}:
>
> to be actioned before interactive editing is allowed. However, the bug
> also permits the variants ei and vx.
The feature(?) and the bug are in ex/vi 3.7 as well, which comes with 4.2BSD.
> The bug was discovered by trying to install a user with the initials 'jei'
> into /etc/passwd.
The fact that mode-line processing can't be turned off is, arguably, a bug
(the same thing may have bitten us here; "vi" acted strangely when editing
/etc/passwd, and I think there was an entry that looked like a mode line).
Somebody posted some changes to "ex" (which apply both the 4.2BSD's 3.7 and
System V Release 2's 3.9) which added a flag "modelines" which, when on,
enabled mode-line processing; the default was to disable mode-line
processing.
Guy Harris
End of article 107 (of 113)--what next? [npq]
From wcs@ho95b.UUCP (Bill Stewart)
Subject: Re: fun bug in vi
Date: 24 May 85 23:28:34 GMT
Date-Received: 25 May 85 06:04:15 GMT
Wayne Allston at ICL had some comments about the "vi-startup-mode" feature:
1) It's undocumented
2) It also accepts ei: and vx: in addition to ex: and vi:
3) It's more of a misfeature than a feature (paraphrased.)
Well, 2) is clearly a bug, and "somebody" ought to fix it. I just checked
the source for version 3.9, and the offending lines of code are still there
in checkmodeline().
However, the startup mode is not undocumented, and it's not a misfeature.
Admittedly, the documentation isn't in the manual page, it's in the file
vax/ex.news in the source directory, but this applies to any features added
since the vi 3.5 version came out. (Hope you've got source! :~)
Whether it's a good feature is somewhat of a religious argument, but I like
it. However, it would be nice to have a modelines/nomodelines option that
you could set in $EXINIT, to make it safer to edit important files, or other
files where the magic sequences might occur.
--
Bill Stewart 1-201-949-0705
AT&T Bell Labs, Room 4K-435, Holmdel NJ
{ihnp4,allegra,cbosgd,vax135}!ho95c!wcs
End of article 105 (of 113)--what next? [npq]
From mark@cbosgd.UUCP (Mark Horton)
Subject: Re: fun bug in vi
Date: 25 May 85 05:13:59 GMT
Date-Received: 25 May 85 12:43:54 GMT
Status: O
This problem is well known - it came out about a year ago.
It has been fixed in vi 3.10. The syntax is now something
that's unlikely to show up by accident in text files, and
very few commands are allowed in a mode line. There
are explicit checks to prevent ! commands, too.
3.10 will probably first be released in System V Release 3.
Mark
End of article 106 (of 113)--what next? [npq]
From guy@sun.uucp (Guy Harris)
Subject: Re: fun bug in vi
Date: 25 May 85 19:27:22 GMT
Date-Received: 27 May 85 01:30:58 GMT
Status: O
> An undocumented feature in vi allows a valid command in the file being
> 'edited' of the form
>
> ...ex:{command}:
> or
> ...vi:{command}:
>
> to be actioned before interactive editing is allowed. However, the bug
> also permits the variants ei and vx.
The feature(?) and the bug are in ex/vi 3.7 as well, which comes with 4.2BSD.
> The bug was discovered by trying to install a user with the initials 'jei'
> into /etc/passwd.
The fact that mode-line processing can't be turned off is, arguably, a bug
(the same thing may have bitten us here; "vi" acted strangely when editing
/etc/passwd, and I think there was an entry that looked like a mode line).
Somebody posted some changes to "ex" (which apply both the 4.2BSD's 3.7 and
System V Release 2's 3.9) which added a flag "modelines" which, when on,
enabled mode-line processing; the default was to disable mode-line
processing.
Guy Harris
End of article 107 (of 113)--what next? [npq]
From honey@down.FUN (Peter Honeyman)
Subject: Re: fun bug in vi
Date: 27 May 85 23:20:06 GMT
Date-Received: 28 May 85 11:59:52 GMT
the fact that the modelines search is for the pattern [ev][xi]: rather
than for (ex|vi): aggravates the problem.
peter
End of article 109 (of 113)--what next? [npq]
From dylan@ibmpcug.co.uk (Matthew Farwell)
Subject: Re: Another VI Question (.exrc file)
Date: Tue, 02 Jun 1992 15:03:23 GMT
In article <1992Jun2.075533.4112@ericsson.se> etxmesa@eos.ericsson.se (Michael Salmon) writes:
>In article <1992Jun1.151852.21819@b15.b15.ingr.com>, smw@wikki.b15.ingr.com (mike wixson) writes:
>|> Since the subject of VI has come up, I've also got a question. I am trying
>|> to find some information about the .exrc file, and the man pages for vi
>|> and ex do not mention very much about it. Can someone direct me to a source
>|> that will explain the what can and cannot be done in the .exrc file?
>|> For example, one thing in that I would like to do is have a command called
>|> ":wn" that would replace ":w" and ":n", but I haven't figured out how to
>|> do this (or if it is even possible).
>:n in fact implies :w (at least on SunOS 4.1.1). I personally map \n
>and \w to :n^M and :w^J respectively. If you are on a Sun system then I
>suggest that you look in the SunOS documentation under Editing Files.
This is only true if autowrite(aw) is set.
Followups to comp.editors.
Dylan.
--
It is no coincidence that in no known language does the phrase 'As
pretty as an Airport' appear -- Douglas Adams
From smw@wikki.b15.ingr.com (mike wixson)
Subject: Another VI Question (.exrc file)
Reply-To: smw@wikki.b15.ingr.com
Date: Mon, 1 Jun 92 15:18:52 GMT
Status: O
Since the subject of VI has come up, I've also got a question. I am trying
to find some information about the .exrc file, and the man pages for vi
and ex do not mention very much about it. Can someone direct me to a source
that will explain the what can and cannot be done in the .exrc file?
For example, one thing in that I would like to do is have a command called
":wn" that would replace ":w" and ":n", but I haven't figured out how to
do this (or if it is even possible).
Thanks!
------------------------------------------------------------
| _ _ Mike Wixson |
| ' )_ _ ' ) wixson@infonode.ingr.com |
| / ) ) / / / ...uunet!ingr!b15!wikki!smw |
| / / / / / / Intergraph 730-1306 |
| / / / * (__(__/ * "Life's a bitch and then |
| you d
Memory fault(coredump)
$
From etxmesa@eos.ericsson.se (Michael Salmon)
Subject: Re: Another VI Question (.exrc file)
Reply-To: etxmesa@eos.ericsson.se (Michael Salmon)
Date: Tue, 2 Jun 1992 07:55:33 GMT
Status: O
In article <1992Jun1.151852.21819@b15.b15.ingr.com>, smw@wikki.b15.ingr.com (mike wixson) writes:
|> Since the subject of VI has come up, I've also got a question. I am trying
|> to find some information about the .exrc file, and the man pages for vi
|> and ex do not mention very much about it. Can someone direct me to a source
|> that will explain the what can and cannot be done in the .exrc file?
|>
|> For example, one thing in that I would like to do is have a command called
|> ":wn" that would replace ":w" and ":n", but I haven't figured out how to
|> do this (or if it is even possible).
:n in fact implies :w (at least on SunOS 4.1.1). I personally map \n and \w to :n^M
and :w^J respectively. If you are on a Sun system then I suggest that you look in
the SunOS documentation under Editing Files.
--
Michael Salmon
#include <standard.disclaimer>
#include <witty.saying>
#include <fancy.pseudo.graphics>
Ericsson Telecom AB
Stockholm
From bill@Celestial.COM (Bill Campbell)
Subject: Re: Another VI Question (.exrc file)
Date: 2 Jun 92 16:21:09 GMT
Status: O
In <1992Jun1.151852.21819@b15.b15.ingr.com> smw@wikki.b15.ingr.com (mike wixson) writes:
:......
:For example, one thing in that I would like to do is have a command called
:":wn" that would replace ":w" and ":n", but I haven't figured out how to
:do this (or if it is even possible).
This one is simple. Use ':set aw' to set autowrite on. Then
when you do :n it will automatically write out the current file
if it's been changed. Autowrite also saves the file any time you
do a shell escape (which for me seems to be about every 30
seconds or so :-) making sure I don't lose data unless I do
something really stupid.
Bill
--
INTERNET: bill@Celestial.COM Bill Campbell; Celestial Software
UUCP: ...!thebes!camco!bill 6641 East Mercer Way
uunet!camco!bill Mercer Island, WA 98040; (206) 947-5591
SPEED COSTS MONEY -- HOW FAST DO YOU WANT TO GO?
From helen@bruno.cs.colorado.edu (Helen Wong)
Subject: .exrc
Date: Sat, 6 Jun 1992 07:03:46 GMT
Status: O
If anyone out there can tell me where I can
find a manual on .exrc? man -k exrc or rc
does not help much. I would really like
to set up my .exrc file ( dont know how ).
Thanks,
Helen -
From smazu@ameris.ameritech.com (Steven P. Mazurek)
Subject: Re: .exrc
Date: Mon, 8 Jun 1992 03:30:50 GMT
Status: O
helen@bruno.cs.colorado.edu (Helen Wong) writes:
>If anyone out there can tell me where I can
>find a manual on .exrc? man -k exrc or rc
>does not help much. I would really like
>to set up my .exrc file ( dont know how ).
".exrc" is NOT a command, but an environment control file for the
"EX" command. If you look in the manual pages for "EX" you should
be able to construct your .exrc file. For example, if you wish
your tab-stops to be four instead of eight every time you use
"EX" or "VI", you'd place the line:
set ts=4
in the .exrc file.
Hope this helps ...
--
Steven P. Mazurek | Email : {...,uunet,bcr,ohumc}!ameris!smazu
Ameritech Services | smazu@ameris.center.il.ameritech.com
Hoffman Estates, IL USA 60196 | Phone : (708) 248-5075
From francis@monod.biol.mcgill.ca (Francis Ouellette)
Subject: Re: .exrc
Date: 8 Jun 92 04:50:22 GMT
Reply-To: francis@monod.biol.mcgill.ca
Status: O
helen@bruno.cs.colorado.edu (Helen Wong) writes:
>
>>If anyone out there can tell me where I can
>>find a manual on .exrc? man -k exrc or rc
>>does not help much. I would really like
>>to set up my .exrc file ( dont know how ).
smazu@ameris.ameritech.com (Steven P. Mazurek) replies:
>
>".exrc" is NOT a command, but an environment control file for the
>"EX" command. If you look in the manual pages for "EX" you should
>be able to construct your .exrc file. For example, if you wish
another place to look is in the very well written "learning
the Vi editor" from our favorite Unix publisher, O'Reilley and
Associates, written by Linda Lamb. You will find all you need
your .exrc file in there.
regards,
francis
---
| B.F. Francis Ouellette
| manager, yeast chromosome I project
| dept of biology, McGill university, Montreal, Qc, Canada
| francis@monod.biol.mcgill.ca
From buboo@alf.uib.no (Ove Ruben R Olsen)
Subject: Re: .exrc
Date: Mon, 8 Jun 92 20:44:36 GMT
Status: O
[... Followup-To: comp.editors where such a question belongs ... ]
Helen Wong writes:
>If anyone out there can tell me where I can
>find a manual on .exrc? man -k exrc or rc
>does not help much. I would really like
>to set up my .exrc file ( dont know how ).
You should check out your nearest VI/EX archive and get some VI documents.
>From one of the INDEX files at the VI/EX archives around the world:
Documentation on VI (main directory):
ex.reference.Z EX Reference Manual. UCB-dist. A Must.
vi.apwh.ms.Z VI Command & Function Reference. UCB-dist.
vi.chars.Z Apendix: character functions. UCB-dist. A Must.
vi.intro.Z Introduction on Display Editing with VI. UCB-dist. A Must.
vi.reference.Z VI reference. Version 7. A Must.
vi.summary.Z VI / EX Quick reference. UCB-dist.
and from the macros/ directory:
(Indeed a good place to look if you want to find things to put in your
$HOME/.exrc file)
exrc.ach - "The Super .exrc File" compiled by Anthony C Howe.
exrc.brp - A nice exrc file from Bill "Rock" Petro.
generals - Some general macros.
generals.2 - More general macros.
jl.ex - Some 'beginer' macros.
There are exstensive INDEX files both in the 'main' directory and in the
macros/ directory.
At the moment there are 137 files in the archives dealing with everyting
from novice introductory VI-courses to a full flegded EMACS emulator.
The VI/EX archives can be found at:
Europe:
Main site: alf.uib.no (129.177.30.3)
Filearea: pub/lpf/misc
Peak hours: 07.00 am GMT to 03.00 pm GMT
Japan:
Mirror site: utsun.s.u-tokyo.ac.jp (133.11.11.11)
Filearea: misc/vi
Peak hours: 01.00 am GMT to 09.00 am GMT
USA, Canada and Mexico:
Mirror site: cs.uwp.edu (131.210.1.4)
Filearea: /pub/vi
Peak hours: None.
Australia, NZ and the rest Down Under:
Main site: monu6.cc.monash.edu.au (130.194.1.106)
Filearea: /pub/Vi
Peak hours: Not relevent
For more information about the files at the archives and the archives
itself, please read one of the FAQ for Comp.Editors.
If you are in a hurry you may fetch the INDEX file.
If you need more information, you are welcome to mail Ove.R.Olsen@uib.no.
\Ruben.
--
Ove Ruben R Olsen, Professional VI user. EMAIL: Ove.R.Olsen@ubb.uib.no
Maintaining the Largest VI/EX-STUFF Archive in the WORLD (alf.uib.no) and
the Comp.Editors FAQ file. If you have information about editing, new editors,
please get in touch with me. This does not apply to EMACS type of editors.
From spencer@burst.Princeton.EDU (S. Spencer Sun)
Subject: Re: .exrc
Reply-To: spencer@phoenix.princeton.edu (S. Spencer Sun)
Date: Tue, 9 Jun 1992 01:56:35 GMT
Status: O
In article <1992Jun8.033050.18825@ameris.ameritech.com>, smazu@ameris.ameritech.com (Steven P. Mazurek) writes:
>helen@bruno.cs.colorado.edu (Helen Wong) writes:
> [reformatted to take up less space --ss]
>>If anyone out there can tell me where I can find a manual on .exrc? man -k
>>exrc or rc does not help much. I would really like to set up my .exrc file
>>( dont know how ).
>
>".exrc" is NOT a command, but an environment control file for the
>"EX" command. If you look in the manual pages for "EX" you should
>be able to construct your .exrc file. For example, if you wish
>your tab-stops to be four instead of eight every time you use
>"EX" or "VI", you'd place the line:
>
> set ts=4
>
>in the .exrc file.
For clarity's sake, just because something is not a command does not
mean you won't find it in the man pages with an apropos. Also, our man
pages (although they may have diddled with them) for ex(1) and vi(1) do
not mention how to set up a .exrc file at all.
The printed version of the Sun manuals should have a booklet called
"Editing Files" or some such which is where I found all that I wanted to
know about .exrc.
----------- The opinions expressed in this article are solely mine. -----------
<Insert lame attempt at disclaimer humor>
sss/PU'94 Dept of CS (spencer@phoenix.princeton.edu)/JvNCnet (spencer@jvnc.net)
"The subtle, truly debilitating manifestations of a degenerate society are
twofold. First, the ruling class no longer cares for the proletariat.
Second, the proletariat no longer cares."
From hamjavar@carina.unm.edu (Farid Hamjavar)
Subject: OK from VI, not from .exrc !!!
Date: Fri, 18 Sep 92 19:58:21 GMT
Hello Everyone :
I have the following in my .exrc ($home or any other directory) :
ab _f @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
map s G :r ~hamjavar/.sig
map v dwelp
map -
set sm
Strange thing is that none of these stuff in .exrc are recognized! They all
work fine when I am in session with VI, but not from .exrc!
ThankS
Farid Hamjavar
hamjavar@carina.unm.edu
From martelli@cadlab.sublink.org (Alex Martelli)
Subject: Re: vi options
Date: 2 Oct 92 11:03:42 GMT
vilva@madras.b23b.ingr.com (Vilva Natarajan) writes:
...
: From inside vi, a ":r!<cmd>" reads in the output of the
: shell command into the file. Is there a way to do this
: on the command line? I tried the -c option as follows
:
: vi -c ":r\!pwd" test
:
: but the command output never shows up in the file.
: Any help would be appreciated.
vi +":r !pwd" test
will work IF file test already exists, but NOT if the file does
not exist beforehand [as once again vi fails the test of least
astonishment...:-(]. Use something like:
touch test;vi -c ":r !pwd" test
to work in either case (the ! must be escaped only in csh and
workalikes, not in ksh and its ilk, so I refuse to escape it!-).
--
Email: martelli@cadlab.sublink.org Phone: ++39 (51) 6130360
CAD.LAB s.p.a., v. Ronzani 7/29, Casalecchio, Italia Fax: ++39 (51) 6130294
From pckizer@tamsun.tamu.edu (Philip Kizer)
Subject: Re: Need help with v -c option
Date: 27 Jan 1993 22:43:50 -0600
Once, westes@netcom.com (Will Estes) writes:
>Also, while I'm here, can someone tell me how do you mark a line
>in .exrc as a comment?
The double quote character: '"'. Like in this snippet from my .exrc:
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
" Insert nroff macro commands before the current para to do full justification.
" Leaves cursor in replace mode to change number of columns.
map \p j{wO.ad b .ll 80 .pl 1kR
"
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
" Pipe the current document through ispell.
" Current documant must already be named. Forces a write of the file.
map \s :w! :!ispell % :e %
-pc
____________________________________________________________ Philip Kizer ___
Texas A&M Unix Workstation Group ( 409 862-4120 ) pckizer@tamu.edu
From hamjavar@hydra.unm.edu (Farid Hamjavar)
Subject: vi's .exrc
Date: 12 Mar 1993 11:31:06 -0600
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
From fuenf@aldebaran.cs.uni-sb.de (Stefan Fuenfrocken)
hi,
i'v got a problem with .exrc file: since vi looks for .exrc in $HOME and
the local directory, my .exrc get red twice, when editing in $HOME giving me
"Too much macro text", and leaving my macros in a very strange state :(
Any way to prevent this?
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
I had some problems with .exrc myself a while back ....
Some kind soul suggested that I should get rid of anything related
to vi's initialization in my .login (e.g. env var such as setenv EXINIT)
Now I have only one .exrc ~/.exrc and that's it.
No matter where I am, this ~/.exrc will be used.
The following , I have not done yet (there was no need) :
You can localize/customize the setting that I just described by
having local .exrc which I am sure vi will be looking for before
looking at anything else.....
Farid Hamjavar
University of New Mexico
From nancym@stein2.u.washington.edu (Nancy McGough)
Subject: vi +/<regexp> <filename> from a shell script
Date: 10 Jul 1993 18:56:49 GMT
Reply-To: nancym@u.washington.edu (Nancy McGough)
>From the command line I can run
vi +/<regexp> <filename>
and have vi open <filename> with the cursor
at the first occurrence of <regexp>. But
if I try to do this from within a shell
script it interprets +/<regexp> as a filename.
Does anyone know how to run this from a
script file?
Thanks much,
Nancy
From hansm@wsinti06.info.win.tue.nl (Hans Mulder)
Subject: Re: vi +/<regexp> <filename> from a shell script
Date: 12 Jul 1993 21:56:49 +0200
In <21n3dh$lqc@news.u.washington.edu> nancym@stein2.u.washington.edu (Nancy McGough) writes:
>From the command line I can run
>vi +/<regexp> <filename>
>and have vi open <filename> with the cursor
>at the first occurrence of <regexp>. But
>if I try to do this from within a shell
>script it interprets +/<regexp> as a filename.
>Does anyone know how to run this from a
>script file?
Put single quotes around the +/<regexp>, e.g.
vi '+/^[0-9]*$' blah
Do this whenever the shell is trying to expand
something that it shouldn't expand.
HansM
From nancym@stein2.u.washington.edu (Nancy McGough)
Subject: Re: vi +/<regexp> <filename> from a shell script
Date: 14 Jul 1993 01:34:23 GMT
Reply-To: nancym@u.washington.edu (Nancy McGough)
hansm@wsinti06.info.win.tue.nl (Hans Mulder) writes:
>Put single quotes around the +/<regexp>, e.g.
>
> vi '+/^[0-9]*$' blah
>
>Do this whenever the shell is trying to expand
>something that it shouldn't expand.
Thanks to Hans and all the people who mailed me with
a solution. Some people mailed and told me they
couldn't reproduce the problem so, fyi, here is
the exact command I was trying to run from a script:
vi +/^sequence $HOME/.nn/init
Anyone know why this works from the command line
but not from a script -- is ^ being interpreted
in some strange way?
Just curious,
Nancy
From hansm@wsinti06.info.win.tue.nl (Hans Mulder)
Subject: Re: vi +/<regexp> <filename> from a shell script
Date: 14 Jul 1993 16:33:05 +0200
In <21vnqv$i51@news.u.washington.edu> nancym@stein2.u.washington.edu (Nancy McGough) writes:
>Anyone know why this works from the command line
>but not from a script -- is ^ being interpreted
>in some strange way?
I'd guess that you're typing your command lines to a C shell
(or maybe a TC shell) and running your scripts in a Bourne shell.
Did you get a message "sequence: not found" from your script?
When you type "sequence" on the command line, do you get
"sequence: Command not found." instead?
If that's the case, you'll have lots of problems, as there are
many, many differences.
You might consider using the Korn SHell or the Bourne Again
SHell as your interactive shell, if available on your system.
In older versions of the Bourne shell ^ is a synonym for | .
HansM
From bcr@cernapo.cern.ch (Bill Riemers)
Subject: Re: vi +/<regexp> <filename> from a shell script
<21vnqv$i51@news.u.washington.edu>
Date: Thu, 15 Jul 1993 18:49:58 GMT
>>>>> On 14 Jul 1993 01:34:23 GMT, nancym@stein2.u.washington.edu (Nancy McGough) said:
Nancy> Thanks to Hans and all the people who mailed me with
Nancy> a solution. Some people mailed and told me they
Nancy> couldn't reproduce the problem so, fyi, here is
Nancy> the exact command I was trying to run from a script:
Nancy> vi +/^sequence $HOME/.nn/init
Nancy> Anyone know why this works from the command line
Nancy> but not from a script -- is ^ being interpreted
Nancy> in some strange way?
Some shells use ^ for history subsitution. In this case you either
need to escape the ^ with \, or you need to change the history subsitution
character. Also your sequence will be interpreted by the shell unless you
enclose it in quotes. It could be that you are using tcsh in this case
your expression ^sequence is being intrepreted as everything not matching
your expression.
Bill
--
"Yeti! Saw them in the London Underground twenty years ago. Ghosts!
A headless woman used to walk through my bedroom at midnight. Mermaids?
Grandpa was rescued from the Marie Celeste by one. Vampires? I always
wondered where my dad went to at night. Telepathy? Right no

194
comp.editors/tab2space Normal file
View File

@ -0,0 +1,194 @@
From etxmesa@eos.ericsson.se (Michael Salmon)
Subject: Re: Q: Tab size in shell
Reply-To: etxmesa@eos.ericsson.se (Michael Salmon)
Date: Fri, 5 Jun 1992 08:53:11 GMT
In article <1992Jun5.065506.27336@nuscc.nus.sg>, ccechk@nuscc.nus.sg (Heng Kek) writes:
|> How does one set the tab size for programs like 'cat', 'more'
|> etc? I edited a table using 'vi' whose tabstop setting is 2
|> (i.e. tabstop=2). When I 'more' the file containing the table,
|> the format is screwed up because the tabs expand to 8 spaces or
|> something.
|>
|> I've gone thru the man pages for 'stty' and tried some stuff but
|> met with no success. Anyone know how to hack this? I'm on
|> ULTRIX 4.2 with vt100 term.
|>
|> Kek
try piping your file through expand.
--
Michael Salmon
#include <standard.disclaimer>
#include <witty.saying>
#include <fancy.pseudo.graphics>
Ericsson Telecom AB
Stockholm
From hansm@wsinti06.info.win.tue.nl (Hans Mulder)
Subject: Re: Vi question (Tab -> space)
Date: 27 May 1993 19:38:33 +0200
In <9305261905.AA23624@corte-madera.geoquest.slb.com> joshi@corte-madera.geoquest.slb.com (Mahesh Govind Joshi) writes:
>Problem:-
>Since each person has his tab_stop key set to his/her preference,
>the file looks unproperly formatted when seen by a person with
>a different tab stop setting.
Solution:
Teach them to leave poor tab_stop alone (i.e. at the value of 8) and to
use shift_width to set indent amount.
Use expand and unexpand to repair existing files.
:map <tab> to control-T if they insist on hitting <tab> to indent.
>It would be most preferable if the tab key was mapped to the space_bar
>key.
>all my guessess/tries with map failed.
You probably didn't type enough control-V's. The line should look like:
:map! ^V ^V
To produce this, type
:
m
a This bit is obvious.
p
!
<space>
control-V This one tells vi-mode to pass the next one to ex-mode.
control-V This one tells ex-mode that the next character is the one
to be map!ped.
<tab> The character to be map!ped
<space>
control-V Same.
control-V Similar.
<space> What it is map!ped to.
If you've done this and try to do again, you'll find that the <tab> gets
replaced by a <space> (that's what :map! is for) and you have to type
a third control-V in the first bunch to tell vi-mode not to do that.
HansM
From rhodesia@wixer.bga.com (Felix S. Gallo)
Subject: Re: Vi question (Tab -> space)
Date: Fri, 28 May 1993 15:33:21 GMT
jafo@miranda.accum.com (Sean Reifschneider) writes:
>
>I set my editor to tabstops=3, shiftwidth=3, and use a tab to indent to the
>next stop for the code. The only time I see problems is when somone edits
>code with their tab stops set to 8, and uses spaces to indent. INDENTING
>IS WHAT TABS ARE THERE FOR.
and the shift key is supposed to shift the hammer tray up so the bottom
half of the hammers strike the paper, etc., etc.
However, back to reality, tabs are nearly utterly useless. I have
3 printers I sometimes have to print to, and 2 of them don't allow you
to define tabstops (!). I've also got a fine terminal which doesn't
like redefinition of tabstops, even though the software thinks it's
gone and done it. I imagine that a lot of people wouldn't mind never
dealing with the headache of tabs ever again.
><shrug> Why don't you just set ts=100, and take off everyones tab keys?
>I know somone who does that.
much easier is
:map! ^V^V^I ^V^V ^V^V
^ ^ ^ ^
| | | |
\_____|____|____/
|
spaces-------/
and, of course, the ^ means 'control-'
>Sean
>--
>"Love is a lot like war... Easy to start but hard to finish."
>Sean Reifschneider, Supreme hack
>jafo@accum.com
--
----------------------------------------------------------------------------
Felix Sebastian Gallo rhodesia@wixer.cactus.org
----------------------------------------------------------------------------
From hansm@wsinti06.info.win.tue.nl (Hans Mulder)
Subject: Re: Vi question (Tab -> space)
Date: 1 Jun 1993 21:06:52 +0200
In <1993May28.153321.5305@wixer.bga.com> rhodesia@wixer.bga.com (Felix S. Gallo) writes:
>jafo@miranda.accum.com (Sean Reifschneider) writes:
>>
>>I set my editor to tabstops=3, shiftwidth=3, and use a tab to indent to the
>>next stop for the code. The only time I see problems is when somone edits
>>code with their tab stops set to 8, and uses spaces to indent. INDENTING
>>IS WHAT TABS ARE THERE FOR.
>and the shift key is supposed to shift the hammer tray up so the bottom
>half of the hammers strike the paper, etc., etc.
No, no, no. The hammers are supposed to strike the ink ribbon. :-)
>><shrug> Why don't you just set ts=100, and take off everyones tab keys?
>much easier is
>:map! ^V^V^I ^V^V ^V^V
> ^ ^ ^ ^
> | | | |
> \_____|____|____/
> |
>spaces-------/
>and, of course, the ^ means 'control-'
This doesn't completely solve the TAB problem: the autoindent option
and the < and > operators _generate_ TABs. To stop vi from doing that,
you'd have to :set ts=100.
Nitpick: the third ^V^V is redundant: only the fFrom nh@cbnewsg.cb.att.com (nicholas.hounsome)
Subject: Re: want spaces not tab chars in vi
Date: 7 May 92 07:23:07 GMT
>From article <1992May7.025815.529@tamsun.tamu.edu>, by dlb5404@tamsun.tamu.edu (Daryl Biberdorf):
> When I use vi on a Sun 4 under SunOs (er, Solaris, whatever) 4.x with
> autoindent ON, the editor seems to use tabs to get the cursor under
> the first character of the previous line. Well, this is fine if I'm
> the only one who edits the file, but my Emacs-using partner is going
> nuts because code that I've edited looks positively screwy on her
> display.
>
> Is there any way to make vi use spaces instead of tab characters when
> it is using autoindent? I can't find it in the manual.
>
> Daryl
>
> --
> Daryl Biberdorf N5GJM dlb5404@rigel.tamu.edu or dlb5404@tamsun.tamu.edu
> Seen on a bumper sticker: "My kid beat up your honor student."
Don't give in to her!!
If everyone sticks to the normal convention of all terminals that I know of,
i.e. tab stops every eight spaces th

91
comp.editors/tabing Normal file
View File

@ -0,0 +1,91 @@
From etxmesa@eos.ericsson.se (Michael Salmon)
Subject: Re: Q: Tab size in shell
Reply-To: etxmesa@eos.ericsson.se (Michael Salmon)
Date: Fri, 5 Jun 1992 08:53:11 GMT
In article <1992Jun5.065506.27336@nuscc.nus.sg>, ccechk@nuscc.nus.sg (Heng Kek) writes:
|> How does one set the tab size for programs like 'cat', 'more'
|> etc? I edited a table using 'vi' whose tabstop setting is 2
|> (i.e. tabstop=2). When I 'more' the file containing the table,
|> the format is screwed up because the tabs expand to 8 spaces or
|> something.
|>
|> I've gone thru the man pages for 'stty' and tried some stuff but
|> met with no success. Anyone know how to hack this? I'm on
|> ULTRIX 4.2 with vt100 term.
|>
|> Kek
try piping your file through expand.
--
Michael Salmon
#include <standard.disclaimer>
#include <witty.saying>
#include <fancy.pseudo.graphics>
Ericsson Telecom AB
Stockholm
From nh@cbnewsg.cb.att.com (nicholas.hounsome)
Subject: Re: damn tabs
Date: 6 Oct 92 07:39:48 GMT
>From article <1992Oct6.040531.25139@cronkite.ocis.temple.edu>, by ray@astro.ocis.temple.edu (Ray Lauff):
> Hello
> I hate the way vi places tabs in the file instead of spaces.
> Don't get me wrong - the Autoindent feature is very spiffy --
> but I hate the <tab> characters it leaves behind.
>
> Right now I use the Unix "expand" command to remove all the
> tabs, but it is a tedious process. Is there a way to request
> vi to replace the tabs with spaces before it saves the file?
>
> Any help appreciated. Thanks in advance.
>
> Ray.
> ray@astro.temple.edu
set tabstop=1000
This will handle autoindent and initial 'tabbing' with ^T but of course
you must never touch the tab key. To get around this type
map! ^V^I ^V ^V ^V ^V ^V
i.e. map tab to however may spaces you want -(be careful with your ^Vs
here)
Of course this is not proper tabbing so you may just want to map it to
one space.
I never understand why people object to tabs apart from when perverts
decide to treat them as other than every 8th position. If it is just
that you want smaller indentation then the trick is to set shiftwidth
and 'tab' in with ^T instead of TAB - To my mind this is realy clever
because it produces your indentation with the minimum possible
number of TABs and spaces.
Nick Hounsome
From hansm@wsinti06.info.win.tue.nl (Hans Mulder)
Subject: Re: TABs in vi
Date: 27 May 1993 19:58:05 +0200
In <1993May27.094810.724@philce.ce.philips.nl> i323856@indus.cad-sg.ce.philips.nl ( DEWENDRA SHASTRI ) writes:
>Dear Netters,
>I want to use the auto-indent feature of vi but it should not put TABs
>for indenting. Is there any setting by which this can be done. Can I
>override TAB with spaces ? If I press TAB key ^I character should not
>be put, instead spaces should be used. Can this be done ?
If you don't want any TAB characters in the file, you can :set tabstop=200
or so. This makes TAB characters show as ridiculous amounts of whitespace
and makes the autoindent feature use ^I characters only if you indent past
column 200.
You'd probably also want t

33
comp.editors/tabs Normal file
View File

@ -0,0 +1,33 @@
From: wcs@ho95e.ATT.COM (#Bill.Stewart)
Subject: Re: Replacing tabs in vi
Date: 23 Jan 87 03:52:20 GMT
Reply-To: wcs@ho95e.UUCP (Bill Stewart 1-201-949-0705 ihnp4!ho95c!wcs HO 2G202)
In article <3050001@hplsdlw.HP.COM> was@hplsdlw.UUCP writes:
>randy@tekla.UUCP (Randy Gibbons) asks:
>> Is there a way in vi to have spaces rather than tabs placed in the
>text.
>Unfortunately, vi has an annoying tendency to auto-indent using tabs. I
>don't know of a way to disable this (mis) feature. However, once the
>tabs are in the file, you can remove them [.......]
> ..... !Gcol -x (replace contents of file with detabbed output of col -x)
(I happen to think tabs are a "good thing"; I'd much rather work in vi
where you get tabs too often than the rand editor which *always*
trashes tabs, even if they were in the original file. The usual
reasons for NOT wanting tabs are that you prefer non-equal tab
settings, or that you use other programs which don't default right.)
To make vi not do tabs when you autoindent, do
:set tabstop=0
This has the negative effect of displaying files with tabs in them a
bit weird (i.e. C programs.), but it means that vi will use spaces
instead of tabs to indent with.
If your real complaint is that you don't like tab stops of size
8, you can set ts=4 sw=4 and then print your programs using options to
expand tabs by +4 (e.g. pr -e4 foo.c)
--
# Bill Stewart, AT&T Bell Labs 2G-202, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs

327
comp.editors/termcap Normal file
View File

@ -0,0 +1,327 @@
From gerolima@Xenon.Stanford.EDU (Mark Gerolimatos)
Subject: Termcap/VI problem...
Date: Sun, 31 May 1992 21:00:20 GMT
Try again....
I am adding in a new termcap entry for some bizarre terminal I bought. Works
fine, except that I can't get VI (and VI only) to take the termcap entry.
Keeps on complaining about unknown terminal types.
Just to be safe, I took a similar termcap entry, copied, and renamed all the
name fields. Nope, VI still didn't take it.
Any suggestions?
-Mark
P.S. Please resond directly, if at all possible
====================================Cut Here====================================
Mark Gerolimatos
gerolima@xenon.stanford.edu "Righteousness comes ONLY from Jesus Christ...
@netlabs.com ...NEVER from an apron."
-Jack T. Chick
================================================================================
From gerolima@Xenon.Stanford.EDU (Mark Gerolimatos)
Subject: RE: Termcap/VI problem (got it, thanks)
Date: Mon, 1 Jun 1992 20:24:01 GMT
Oops, forgot to mention that I am running SunOS 4.1.1
Turns out that vi (as in /usr/UCB/vi) uses termINFO in SunOs. Why,
I'll never figure out. That was the problem.
Thanx to all those who helped.
-Mark
====================================Cut Here====================================
Mark Gerolimatos
gerolima@xenon.stanford.edu "Righteousness comes ONLY from Jesus Christ...
@netlabs.com ...NEVER from an apron."
-Jack T. Chick
"La justicia viene so'lo por Jesucristo
...NUNCA por un delantar."
-por Jack. T. Chick
================================================================================
From terry@npd.Novell.COM (Terry Lambert)
Subject: Re: Termcap/VI problem...
Date: 1 Jun 92 22:57:27 GMT
In article <1992May31.210020.10270@CSD-NewsHost.Stanford.EDU> gerolima@Xenon.Stanford.EDU (Mark Gerolimatos) writes:
>Try again....
>
>I am adding in a new termcap entry for some bizarre terminal I bought. Works
>fine, except that I can't get VI (and VI only) to take the termcap entry.
>Keeps on complaining about unknown terminal types.
>
>Just to be safe, I took a similar termcap entry, copied, and renamed all the
>name fields. Nope, VI still didn't take it.
>
>Any suggestions?
It is nearly 100% likely that your vi uses TERMINFO, *not* TERMCAP
as the means of determining what escape sequences to use. This is true of
SunOS and most SysV binary distributions.
How to find out from the csh:
strings `which vi` | grep term
You'll see a message similar to one of the following::
corrupted terminfo entry
terminfo entry too long
terminfo file for "%s" terminal is not readable
Ie: This vi was linked -ltermlib
or something similar to:
incomplete termcap entry
Ie: this vi was linked with -ltermcap
To solve your problem if this is the case:
Download 'captoinfo' from your friendly neighborhood archive,
compile it, and run it (alternately, you could learn to write terminfo
entries).
If you can get a hold of a System V box that has the terminfo
of interest:
To get a terminfo file from an already compiled terminfo database that
doesn't have the source around (SCO is famous for this):
System V (at least) has a command called "infocmp" which will
dump an ASCII version of the compiled terminfo source for the terminal
currently referred to by the TERM environment variable.
Terry Lambert
terry_lambert@gateway.novell.com
terry@icarus.weber.edu
--
my present or previous employers.
From jpr@jpradley.jpr.com (Jean-Pierre Radley)
Subject: Re: Termcap/VI problem...
Date: Tue, 02 Jun 1992 03:56:15 GMT
In article <1992May31.210020.10270@CSD-NewsHost.Stanford.EDU> gerolima@Xenon.Stanford.EDU (Mark Gerolimatos) writes:
>I am adding in a new termcap entry for some bizarre terminal I bought. Works
>fine, except that I can't get VI (and VI only) to take the termcap entry.
>Keeps on complaining about unknown terminal types.
>Just to be safe, I took a similar termcap entry, copied, and renamed all the
>name fields. Nope, VI still didn't take it.
>Any suggestions?
I suggest that you provide your version of Unix when you post such a question.
It is possible that your version of 'vi' knows nothing about termcap, and is
using terminfo instead.
>P.S. Please resond directly, if at all possible
You post here, you read here...
>====================================Cut Here====================================
>
> Mark Gerolimatos
>
>gerolima@xenon.stanford.edu "Righteousness comes ONLY from Jesus Christ...
> @netlabs.com ...NEVER from an apron."
> -Jack T. Chick
>
>================================================================================
Your signature is abusively long. Not its contents, its length.
Please recall that the news.* files suggest that 4 lines is sufficient for a
signature block.
--
Jean-Pierre Radley Unix in NYC jpr@jpr.com jpradley!jpr CIS: 72160,1341
From gert@greenie.gold.sub.org (Gert Doering)
Subject: Re: Termcap/VI problem...
Date: 2 Jun 92 14:26:35 GMT
gerolima@Xenon.Stanford.EDU (Mark Gerolimatos) writes:
>I am adding in a new termcap entry for some bizarre terminal I bought. Works
>fine, except that I can't get VI (and VI only) to take the termcap entry.
>Keeps on complaining about unknown terminal types.
If you had told us what kind of Unix you are using, it would be easier to
answer...
Nevertheless, on many unices VI uses not termcap but terminfo.
gert
--
Gert Doering | SubNet : gert@greenie.gold.sub.org | mailbox / uucp:
Munich / FRG | InterNet: gdoering@physik.tu-muenchen.de | call (089)3243328
(089)3243228 | FidoNet : gert.doering@2:246/55.4 | login bbs / nuucp
From gert@greenie.gold.sub.org (Gert Doering)
Subject: Re: Termcap/VI problem (got it, thanks)
Date: 2 Jun 92 21:41:15 GMT
gerolima@Xenon.Stanford.EDU (Mark Gerolimatos) writes:
>Turns out that vi (as in /usr/UCB/vi) uses termINFO in SunOs. Why,
>I'll never figure out. That was the problem.
Why? Because terminfo is far superior to termcap - more features, faster
access.
gert
--
Gert Doering | SubNet : gert@greenie.gold.sub.org | mailbox / uucp:
Munich / FRG | InterNet: gdoering@physik.tu-muenchen.de | call (089)3243328
(089)3243228 | FidoNet : gert.doering@2:246/55.4 | login bbs / nuucp
From guy@Auspex.COM (Guy Harris)
Subject: Re: Termcap/VI problem (got it, thanks)
Date: 4 Jun 92 23:04:19 GMT
>>Turns out that vi (as in /usr/UCB/vi) uses termINFO in SunOs. Why,
>>I'll never figure out. That was the problem.
>
>Why? Because terminfo is far superior to termcap - more features, faster
>access.
It may be (although you'll probably find plenty of people who don't
think it's better; I'm pretty much neutral, so I'll let those people
jump into the fray - preferably in "comp.unix.questions"), but it
*wasn't* the reason.
The reason was very simple:
1) we wanted an 8-bit clean "vi" for SunOS 4.1, to handle character sets
such as ISO Latin #1;
2) the SVR3.1 "vi" was already 8-bit clean;
3) making the BSD "vi" 8-bit clean looked like a real chore;
4) the SVR3.1 "vi" used "terminfo";
5) making the SVR3.1 "vi" use "termcap" looked like a real chore;
6) "vi" is such a sewer that nobody particularly wanted to undertake
either of those chores;
so we just dropped in the SVR3.1 "vi", with some changes to make it
build under SunOS's SV environment (which, in 4.1[.x], doesn't have
every single library or library routine from SVR3.1; the undocumented
"-lgen" was left out, as were AT&T's decidedly non-standard routines for
fetching character set information for the locale - we used the routines
from the ANSI C draft standard, instead).
That also picked up a bunch of post-version-3.7 bug fixes, and various
other features such as "showmode"; "set showmode" puts an indicator on
the bottom line showing what mode you're in.
From terry@npd.Novell.COM (Terry Lambert)
Subject: Re: Termcap/VI problem (got it, thanks)
Date: Fri, 5 Jun 1992 17:53:07 GMT
In article <1992Jun02.214115.11997@greenie.gold.sub.org> gert@greenie.gold.sub.org (Gert Doering) writes:
>gerolima@Xenon.Stanford.EDU (Mark Gerolimatos) writes:
>
>>Turns out that vi (as in /usr/UCB/vi) uses termINFO in SunOs. Why,
>>I'll never figure out. That was the problem.
>
>Why? Because terminfo is far superior to termcap - more features, faster
>access.
Superior features like "we thought of everything, so you can't possibly need
to extend it, so we'll use a static structure for reading the file"?
Faster access depends on how you set it up. It's perfectly acceptable to
have your TERMCAP environment variable contain your entire termcap string;
this means that it's already in your address space, automagically, when you
run your app. See 'tset' (UNIX) and 'resize' (X).
If I want better than ISO (8 color) escape sequences, at least I have a way
to get them using termcap.
The other drawback to terminfo is that if you don't have 'infocmp' and you
don't have terminfo source (many AT&T distributions left terminfo source
out), you have to write 'infocmp' or suffer with factory bugs. It's
relatively easy, on the other hand, to edit /etc/termcap. One glaring
use for this is to set "protect" to be reverse video on a Wyse-50, and
use it From gerolima@Xenon.Stanford.EDU (Mark Gerolimatos)
Subject: Termcap/VI problem...
Date: Sun, 31 May 1992 21:00:20 GMT
Try again....
I am adding in a new termcap entry for some bizarre terminal I bought. Works
fine, except that I can't get VI (and VI only) to take the termcap entry.
Keeps on complaining about unknown terminal types.
Just to be safe, I took a similar termcap entry, copied, and renamed all the
name fields. Nope, VI still didn't take it.
Any suggestions?
-Mark
P.S. Please resond directly, if at all possible
====================================Cut Here====================================
Mark Gerolimatos
gerolima@xenon.stanford.edu "Righteousness comes ONLY from Jesus Christ...
@netlabs.com ...NEVER from an apron."
-Jack T. Chick
================================================================================
From terry@npd.Novell.COM (Terry Lambert)
Subject: Re: Termcap/VI problem...
Date: Wed, 3 Jun 1992 16:37:22 GMT
In article <1992Jun02.035615.5315@jpradley.jpr.com> jpr@jpradley.jpr.com (Jean-Pierre Radley) writes:
>In article <1992May31.210020.10270@CSD-NewsHost.Stanford.EDU> gerolima@Xenon.Stanford.EDU (Mark Gerolimatos) writes:
>>====================================Cut Here====================================
>>
>> Mark Gerolimatos
>>
>>gerolima@xenon.stanford.edu "Righteousness comes ONLY from Jesus Christ...
>> @netlabs.com ...NEVER from an apron."
>> -Jack T. Chick
>>
>>================================================================================
>
>Your signature is abusively long. Not its contents, its length.
>Please recall that the news.* files suggest that 4 lines is sufficient for a
>signature block.
>--
>Jean-Pierre Radley Unix in NYC jpr@jpr.com jpradley!jpr CIS: 72160,1341
====================================Cut Here====================================
*****Mark Gerolimatos**gerolima@xenon.stanford.edu*"Righteousness comes ONLY fro
m Jesus Christ...**@netlabs.com***...NEVER from an apron."*******-Jack T. Chick*
*
====================

30
comp.editors/toodanger Normal file
View File

@ -0,0 +1,30 @@
From fuenf@aldebaran.cs.uni-sb.de (Stefan Fuenfrocken)
Subject: "too dangerous to map that"
Date: 27 Jan 1993 09:05:45 GMT
PathPath: aldebaran!fuenf
Hi,
Under what circumstance do i get the " too dangerous to map that" message?
There were a few times vi refused to map something.
e.g. perform search for fixed patten
:map xx /pattern
Does this mean, that i probably will run into conflict with 'internal' vi mappings?
Is there a way to do the mapping anyway.
e.g: space bar mapping (well, bad example, since it is not too dangerous to map ;) )
map ^V something
an then redefine the mappings for 's' and '~', which use the spacebar-mapping,
accordingly with the 'l' as substitute.
Another question:
-) is there a way to use the 'unmapped' meaning of mapped symbols?
suppose you map! the ESC-key to somthing (a stupid thing, i know ;) ), which
leaves you with (almost) no possibility to return from any insert/appand/open mode;
the only thing a can imagine, is to map! an other key to ESC ( with noremap

392
comp.editors/toomuch Normal file
View File

@ -0,0 +1,392 @@
From tfoley@bnr.ca (Tristram Colville-Foley)
Subject: Still too much macro text!
Date: Mon, 06 Jul 1992 09:21:35 GMT
I have been struggling to get round the now all too familiar `Too much
macro text' error message. I am sourcing the macros when I need them,
and not putting them in my .exrc, but after using them for a short period
of time, I get the above error message. Unmapping them doesn't work, but
if I can set up a macro to exit and then re-enter the file, now that
would be cool! Even better if I can come back to the place I was at.
How about a command echo the filename into a temporary file. Then I
could exit the vi session, read the temporary file and start up
another session.
Any ideas?
P.S. I have found that if you want to unmap a whole series of mappings
by sourcing a file, you must make the file look like this.
unmap this|
unmap that|
unabbreviate this_as_well| <--- with the pipe symbol at the end, otherwise
you get silly errors like,
`That macro wasn't mapped'
Sorry if this is obvious but it took several attempts and lots of head
banging before I figured it out.
From cameron@spectrum.cs.unsw.oz.au (Cameron Simpson)
Subject: Re: Too much macro text
Reply-To: cameron@spectrum.cs.unsw.oz.au (Cameron Simpson)
Date: Tue, 7 Jul 1992 09:57:36 GMT
In article <1992Jul2.114727.24357@cas.org> lvirden@cas.org (Larry W. Virden) writes:
| In article <1992Jul1.134106.16089@news.eng.convex.com> tchrist@convex.COM (Tom Christiansen) writes:
| :From the keyboard of tfoley@bnr.ca (Tristram Colville-Foley):
| ::Any way I can get round this?
| :
| :Not easily. My bandaid solution was to re-compile vi with
| :a much larger buffer. I took the liberty of upping things
| :like line length and macro space by an order of magnitude.
|
| There IS one thing that you can try. Put your macros into some file
| OTHER than $HOME/.exrc . Do NOT source it in during $HOME/.exrc. Instead,
| source it in when you need it.
And bypass macros as much as possible. My mail reader is a small Perl script
to update an index file and a set of vi macros. I append it as a shar file
later.
Anyway, it sources on startup two files, which I list here:
The first file sets some catches for unused maps:
map \M !!
map Z
map \d
map \h
map \r
map \s
map \v
The second sets up the macros for perusing the index:
map \d :so .ex/index-d
map \h
map \r :so .ex/index-r
map \s
map \v :so .ex/index-v
" map + :so .ex/+
As much work as possible is done as ex-mode commands, reducing the macro text
(which I think maxes out at 128 characters on this system. Jeez.)
| I suppose one thing one might do is add a bunch of unmaps to the beginning
| of the file so that you clear out previous macros before defining new ones -
| anyone know if that will reclaim space?
I tried this:
- vi complains and aborts the command sequence if you unmap something
which wasn't mapped. Hence the first file shown above.
- there's a space leak of some kind. The unmaps don't get back nearly
enough. I gave them up.
- there's leaks in the remapping, too. Eventually my mail reader spins
out (harmlessly so far) and I have to leave and re-enter. Fortunately
this is pretty painless; it starts up fast.
Peeves:
- vi aborts on an error. This is mostly ok, but it considers failed
searches an error. I may have to replace .ex/reply (below) with
something like
f reply
%!make-reply
This would be slower as it involves using another program.
- Worse! Vi (here, anyway) picks up next time in the middle of whatever
sequence it aborted. Totally weird. I suspect a local bug.
Anyone know how to do conditional code in vi?
- Cameron Simpson
cameron@cs.unsw.oz.au
#!/bin/sh
#
mkdir cameron && cd cameron && mkdir .ex .pl bin || exit $?
sed 's/^X//' > '.pl/updindex.pl' <<'EOF-//fuligin/1/cameron/etc/mail/.pl/updindex.pl'
X#!/usr/local/bin/perl
X#
X
X$cmd=$0;
X
X@INDEX=();
Xundef %indexed;
Xif (open(INDEX,"< .index"))
X { while (<INDEX>)
X { push(@INDEX,$_);
X next if !/^\s*(\d+)/;
X
X $indexed{$1}=$#INDEX;
X }
X
X close(INDEX);
X }
Xelse
X{ print STDERR "can't open .index: $!\n";
X}
X
Xif (opendir(DIR,"."))
X { @files=grep(/^\d+$/ && !defined($indexed{$_}),readdir(DIR));
X closedir(DIR);
X }
Xelse
X{ @files=();
X print STDERR "can't opendir .: $!\n";
X}
X
X$xtra=0;
Xfor $F (@files)
X { if (!open(F,"< $F\0"))
X { print STDERR "$cmd: can't open \"$F\": $!\n";
X next;
X }
X
X $to='';
X $from='';
X $subject='';
X while (<F>)
X { last if /^$/;
X next if /^\s/;
X
X ($field,$body)=/^([^:\s]*):\s*(.*)/;
X $field =~ tr/A-Z/a-z/;
X if ($field eq 'subject') { $subject=$body; }
X elsif ($field eq 'from') { $from=$body; }
X elsif ($field eq 'to') { $to=$body; }
X }
X
X close(F);
X
X if ($from =~ /\(\s*(\S.*\S)\s*\)/
X || $from =~ /(\S.*\S)\s*<\S*@\S*>\s*$/)
X { $from=$1;
X }
X
X push(@INDEX,sprintf("%5d %-17.17s %s\n",
X $F,length($from)?$from:"To: $to",$subject
X )
X );
X $indexed{$F}=$#INDEX;
X print STDERR $INDEX[$#INDEX];
X $xtra=1;
X }
X
Xif ($xtra)
X { print STDERR "updating .index ...\n";
X if (open(INDEX,"> .index"))
X { for (sort bynum keys %indexed)
X { print INDEX $INDEX[$indexed{$_}];
X }
X
X close(INDEX);
X }
X else
X { print STDERR "$cmd: can't rewrite .index: $!\n";
X }
X }
X
Xsub bynum
X { # print STDERR "\"$a\" <=> \"$b\"=".(($a+0) <=> ($b+0))."\n";
X ($a+0) <=> ($b+0);
X }
EOF-//fuligin/1/cameron/etc/mail/.pl/updindex.pl
sed 's/^X//' > 'bin/vmail' <<'EOF-//fuligin/1/cameron/bin/vmail'
X#!/bin/sh
X#
X# Enter my mail folder and run vi as a user agent.
X#
X
XMAILDIR=${MAILDIR-$HOME/etc/mail}
Xexport MAILDIR
X
Xcase "$1" in
X '') folder=$MAILDIR/inbox ;;
X /*) folder=$1 ;;
X +*) folder=$MAILDIR/`exec expr "$1" : '+\(.*\)'` ;;
X *) folder=$MAILDIR/$1 ;;
Xesac
X
Xcd "$folder" || exit $?
Xperl .pl/updindex.pl
Xexec vi '+so .ex/map|so .ex/index-map|$' .index
EOF-//fuligin/1/cameron/bin/vmail
sed 's/^X//' > '.ex/+' <<'EOF-//fuligin/1/cameron/etc/mail/.ex/+'
Xmap \M :e! .index
EOF-//fuligin/1/cameron/etc/mail/.ex/+
sed 's/^X//' > '.ex/ctrl-m' <<'EOF-//fuligin/1/cameron/etc/mail/.ex/ctrl-m'
Xmap!
EOF-//fuligin/1/cameron/etc/mail/.ex/ctrl-m
sed 's/^X//' > '.ex/index' <<'EOF-//fuligin/1/cameron/etc/mail/.ex/index'
Xn .index
Xso .ex/index-map
EOF-//fuligin/1/cameron/etc/mail/.ex/index
sed 's/^X//' > '.ex/index-d' <<'EOF-//fuligin/1/cameron/etc/mail/.ex/index-d'
Xs/^ *\([^ ]*\).*/mv \1 $MAILDIR\/deleted\&
X.w !sh
Xd
EOF-//fuligin/1/cameron/etc/mail/.ex/index-d
sed 's/^X//' > '.ex/index-map' <<'EOF-//fuligin/1/cameron/etc/mail/.ex/index-map'
Xmap \d :so .ex/index-d
Xmap \h
Xmap \r :so .ex/index-r
Xmap \s
Xmap \v :so .ex/index-v
X" map + :so .ex/+
EOF-//fuligin/1/cameron/etc/mail/.ex/index-map
sed 's/^X//' > '.ex/index-r' <<'EOF-//fuligin/1/cameron/etc/mail/.ex/index-r'
X.t.
Xs/^ *\([^ ]*\).*/n \1|so .ex\/reply
X.w! fnord
Xd
Xso fnord
EOF-//fuligin/1/cameron/etc/mail/.ex/index-r
sed 's/^X//' > '.ex/index-v' <<'EOF-//fuligin/1/cameron/etc/mail/.ex/index-v'
X.t.
Xs/^ *\([^ ]*\).*/n \1|so .ex\/mail
X.w! fnord
Xd
Xso fnord
EOF-//fuligin/1/cameron/etc/mail/.ex/index-v
sed 's/^X//' > '.ex/mail' <<'EOF-//fuligin/1/cameron/etc/mail/.ex/mail'
Xmap \d :!mv % $MAILDIR/deleted >/dev/null&
Xmap \h :so .ex/index
Xmap \r :so .ex/reply
Xmap \s
Xmap \v
EOF-//fuligin/1/cameron/etc/mail/.ex/mail
sed 's/^X//' > '.ex/mailto' <<'EOF-//fuligin/1/cameron/etc/mail/.ex/mailto'
Xw!
Xf mailto
Xmap \h :n .index
Xmap \r
Xmap \s :so .ex/reply-s
Xmap \d :so .ex/reply-d
Xmap \v
X1s/^/
X1
X/^From:/t0
X1s/^From/To
X/^$/+1,$s/^/|
X1
X/^| Subject:/t1
X2s/|
Xw!
EOF-//fuligin/1/cameron/etc/mail/.ex/mailto
sed 's/^X//' > '.ex/map' <<'EOF-//fuligin/1/cameron/etc/mail/.ex/map'
Xmap \M !!
Xmap Z
Xmap \d
Xmap \h
Xmap \r
Xmap \s
Xmap \v
EOF-//fuligin/1/cameron/etc/mail/.ex/map
sed 's/^X//' > '.ex/reply' <<'EOF-//fuligin/1/cameron/etc/mail/.ex/reply'
Xw!
Xf reply
Xmap \h :n .index
Xmap \r
Xmap \s :so .ex/reply-s
Xmap \d :so .ex/reply-d
Xmap \v
X1s/^/
X1
X/^From:/t0
X1s/^From/To
X/^$/+1,$s/^/|
X1
X/^| Subject:/t1
X2s/|
Xw!
EOF-//fuligin/1/cameron/etc/mail/.ex/reply
sed 's/^X//' > '.ex/reply-d' <<'EOF-//fuligin/1/cameron/etc/mail/.ex/reply-d'
Xw>>dead.letter
Xso .ex/index
EOF-//fuligin/1/cameron/etc/mail/.ex/reply-d
sed 's/^X//' > '.ex/reply-s' <<'EOF-//fuligin/1/cameron/etc/mail/.ex/reply-s'
Xw!
X!smail <% &
X0r!echo From $USER `date`
X1s/[^ ][^ ]* \([0-9]*\)$/\1
Xw!
X!filemail -m $MAILDIR/outmail <%
Xso .ex/index
EOF-//fuligin/1/cameron/etc/mail/.ex/reply-s
exit 0
From Tom Christiansen <tchrist@convex.COM>
Subject: Re: Too much macro text
Reply-To: tchrist@convex.COM (Tom Christiansen)
Date: Wed, 1 Jul 1992 13:41:06 GMT
Corp. The opinions expressed are those of the user and
not necessarily those of CONVEX.
>From the keyboard of tfoley@bnr.ca (Tristram Colville-Foley):
:I am implementing a programming mode and its looking good. Only problem is I
:can't finish it because I have reached the limits of the vi macro capabilities.
:Any way I can get round this?
Not easily. My bandaid solution was to re-compile vi with
a much larger buffer. I took the liberty of upping things
like line length and macro space by an order of magnitude.
But since we don't have a real vi with source, not everyone
can do this. Instead, they're at the mercy of their vendors,
who are amazingly lethargicly at fixing things. Then you've
got some TLA vendors who've stepped back into the past somehow
and broken existing versions of vi.
The following message from EDZ might someday help ameliorate
these problems.
Date: 30 Jun 92 19:48:30 GMT
From: zwicky@erg.sri.com (Elizabeth Zwicky)
Subject: Re: Why don't vendors update std utilities?
Organization: SRI International, Menlo Park, CA
Newsgroups: comp.unix.questions
Message-ID: <1992Jun30.194830.6324@erg.sri.com>
One of the projects that has been suggested for the SAGE electronic
information distribution working group is the development of a
third-party bugs database. One of my favorite visions of using such a
database involves taking one of these common bugs in a standard
utility, calling up one vendor, and saying "This bug has been reported
against four vendors. One of them issued a patch. One of them said it
would be fixed in the next release. Now it's your turn; you can do as
well as your competitors, or not, and the direct comparison will be in
the database for all the world to see." (It's right up there with "No,
I don't think I am the only person with the bug; right here I see it
being reported by 18 people in 5 different countries.")
More information about joining this working group is available by
sending mail to "sage-online-request@usenix.org". SAGE is the USENIX
System Administrators' Guild, a USENIX special technical group devoted
to system administration interests; to join its mailing list, send
mail to "sage-request@usenix.org".
Elizabeth D. Zwicky
zwicky@erg.sri.com
--tom
--
Tom Christiansen tchrist@convex.com convex!tchrist
Emacs

226
comp.editors/transfer Normal file
View File

@ -0,0 +1,226 @@
From david@cats.ucsc.edu (David Wright)
Subject: Re: Transferring lines between files in VI
Date: 8 Aug 92 03:56:57 GMT
In article <1683CE217.S947460@UMSLVMA.UMSL.EDU> S947460@UMSLVMA.UMSL.EDU writes:
|How can I transfer a few lines of text from one file to another
|using VI ?
|I tried yy , :e another file and then p, but it seems that
|yank/paste buffer is not preserved when I do this.
This is an easy one.
If you have set number on, you can give the command:
:4,54 w>> otherfile
A more intuitive way is to yank into a named register. This will be
preserved when you
:e otherfile
you can put it when you get to that file.
I use a macro that puts cut or pasted text into the register a, with the
command [ (Cut) or ] (delete). I then :e otherfile and use to put it:
map "ap
map [ "ay'a
map ] "ad'a
--
|^^^^^^| _______________________________________________________
| | |"There is nothing in the marginal conditions that |
| | | distinguish a mountain from a mole hill" |
| (o)(o) O Kenneth Boulding |
@ _) o|_____________________________________________________|
| ____\ o o
| /
/ \ All comments are mine---(David Wright)
From hc05@rexago8.uucp (Beirne Konarski)
Subject: Re: Transferring lines between files in VI
Date: Sat, 8 Aug 1992 12:32:36 GMT
S947460@UMSLVMA.UMSL.EDU writes:
>How can I transfer a few lines of text from one file to another
>using VI ?
>I tried yy , :e another file and then p, but it seems that
>yank/paste buffer is not preserved when I do this.
Try
"ayy
:e other-file
"ap
The buffer holding the last action is cleared when a file is changed, but named
buffers are not.
--
-------------------------------------------------------------------------------
Beirne Konarski | Reading maketh a full man, conference a
...uunet!rexago8!hc05 | ready man, and writing an exact man.
hc05%rexago8@uunet | -- Francis Bacon
From S947460@UMSLVMA.UMSL.EDU
Subject: Transferring lines between files in VI
Date: 7 Aug 92 21:04:38 GMT
How can I transfer a few lines of text from one file to another
using VI ?
I tried yy , :e another file and then p, but it seems that
yank/paste buffer is not preserved when I do this.
From wyle@synopsys.com (Mitch Wyle)
Subject: Re: Transferring lines between files in VI
Date: 10 Aug 92 21:14:49 GMT
If you know that you want to copy all lines between parenthesis
or braces or brackets, you don't have to count lines; you
can use the % match command.
>Yanked text is not accessible across the files. But if you yank in the
>named registers, you can use them across the files.
>
>try,
>
>"a10yy : "a for using named register a, you can use a thr z registers,
> : and say you want to yank 10 lines,
>
"ay%
to grab the text.
If the entity is a paragraph, then
"ay}
will yank to the end of the paragraph boundary.
It is almost never necessary to count lines. Getting in the habit of moving
and yanking using objects like sections, sentences, next close-parenthesis
etc. is useful.
>then goto the other file by
>
>:e other_file
>
>and
>put the yanked contents before a current line as
>
>"aP
>
>hope it helps,
>
>nitin
>Nitin Kaulavkar, <nitin@cse.iitb.ernet.in>
>Dept of Computer Science & Engg,IIT, Bombay 400 076.
Mitch Wyle (415) 694 4076 (work)
Synopsys Inc (408) 263 3063 (home)
700 E. Middlefield Rd. (415) 965 8637 (fax)
Mountain View, CA 94043-4033 (800) 843 5669 x4076 (voice)
wyle@synopsys.com (415) 807 6632 (pager)
From david@cats.ucsc.edu (David Wright)
Subject: Re: Transferring lines between files in VI
Date: 8 Aug 92 03:56:57 GMT
In article <1683CE217.S947460@UMSLVMA.UMSL.EDU> S947460@UMSLVMA.UMSL.EDU writes:
|How can I transfer a few lines of text from one file to another
|using VI ?
|I tried yy , :e another file and then p, but it seems that
|yank/paste buffer is not preserved when I do this.
This is an easy one.
If you have set number on, you can give the command:
:4,54 w>> otherfile
A more intuitive way is to yank into a named register. This will be
preserved when you
:e otherfile
you can put it when you get to that file.
I use a macro that puts cut or pasted text into the register a, with the
command [ (Cut) or ] (delete). I then :e otherfile and use to put it:
map "ap
map [ "ay'a
map ] "ad'a
--
|^^^^^^| _______________________________________________________
| | |"There is nothing in the marginal conditions that |
| | | distinguish a mountain from a mole hill" |
| (o)(o) O Kenneth Boulding |
@ _) o|_____________________________________________________|
| ____\ o o
| /
/ \ All comments are mine---(David Wright)
From nitin@kailash.arjun (Nitin Kaulavkar)
Subject: Re: Transferring lines between files in VI
Date: Sun, 9 Aug 1992 09:37:59 GMT
In article <1683CE217.S947460@UMSLVMA.UMSL.EDU> S947460@UMSLVMA.UMSL.EDU writes:
From: S947460@UMSLVMA.UMSL.EDU
Newsgroups: comp.editors
Date: 7 Aug 92 21:04:38 GMT
Sender: root@parsifal.umkc.edu (Parsifal Administration)
Organization: UM ST. LOUIS
Lines: 4
How can I transfer a few lines of text from one file to another
using VI ?
I tried yy , :e another file and then p, but it seems that
yank/paste buffer is not preserved when I do this.
Yanked text is not accessible across the files. But if you yank in the
named registers, you can use them across the files.
try,
"a10yy : "a for using named register a, you can use a thr z registers,
: and say you want to yank 10 lines,
then goto the other file by
:e other_file
and
put the yanked contents before a current line as
"aP
For more details, read about the named registers. You can do a lot of
intersting stuff with them
hope it helps,
nitin
--
Nitin Kaulavkar, <nitin@cse.iitb.ernet.in>
Dept of Computer Scien

70
comp.editors/undo Normal file
View File

@ -0,0 +1,70 @@
From: pgf@cayman.COM (Paul Fox)
Subject: Re: Undoing, Emacs and unlimited files ... summery.
Date: 27 Jul 92 19:51:02 GMT
Organization: Cayman Systems Inc., Cambridge Ma
nmouawad@waterloo.edu (Naji Mouawad) writes:
:
... a nice summary of undo strategies in various editors
:
Gee, if I'd known everyone was going to be so informative, I'd have replied
to the original posting -- but better late than never: since it's just a
little different than the other method's described, here's how vile does
undo:
(Note this is a vi-style "one command" undo, which undoes itself -- it is
not an "infinite" undo.)
[ vile uses the linked list method of storage, with dynamically allocated
text blocks hanging off of each line "header". ]
Undo operates by keeping a stack of "changed" lines (i.e. those affected
by a given command), along with information (more later) as to where they
should go if an undo is actually required. Thus if a character is deleted
on a line, a copy of the original line is pushed on the undo stack. If a
line is deleted, is simply moved to the undo stack. If a line is inserted,
a "tag" is pushed on the undo stack, which tells us where the corresponding
deletion should occur at undo time. Only the first change to a line causes a
copy to be stacked -- at that point, the line is flagged as having been
copied already, suppressing further copies. Since undo is itself undoable,
I found it easiest to keep two undo stacks -- when we do an undo, the
changes we are now undoing are simply put onto the alternate undo stack.
Multiple undo commands in a row simply cause us to move from one stack of
changes to the other (rebuilding the other each time).
A certain amount of grottiness comes in because what we store as the
information needed to put the lines back in their place are actually
pointers to the lines in front and in back of its original location. Since
these pointers may be invalidated by subsequent changes during the same
command (if, say, the line following a changed line goes away altogether),
we need to store some pointer patches on the stack as weil, which, in
essence, say "when you pop this, go down through the stack and change all
instances of pointer A to pointer A', because that's its new value". I
didn't say it was beautiful. I would probably do things differently if I
were to do it now -- I knew _nothing_ about editors when I started
converting micro-Emacs to vile.
One advantage of this stack approach is that it simply accumulates all
changes to a buffer until told to clean up the stacks. Thus it was trivial
to make global operations (:g/str1/s/str2/str3") and macros (like a set of
commands executed with '@a', or via the keyboard macro-recorder) undoable
all at once. The first case just worked, and for the second, I simply
delay the stack cleanup if a macro replay is in progress.
Vi connosewers (sp? :-) will note that this is different than the stock vi
approach, in that it is totally independent of the default yank buffer.
That is, doing an undo will not affect the contents of the yank buffer. I
consider this a feature.
paul fox, pgf@cayman.com
(yes, it's available for ftp -- at ftp.cayman.com:/pub/vile)
--
paul fox, pgf@cayman.com, (617)494-1999
Cayman Systems, 26 Landsdowne St., Cambridge, MA 02139

138
comp.editors/vim Normal file
View File

@ -0,0 +1,138 @@
From alf.uib.no!trane.uninett.no!sunic!pipex!uunet!usc!sdd.hp.com!col.hp.com!csn!boulder!ucsu!spot.Colorado.EDU!siffert Thu Jul 15 18:23:34 MET DST 1993
Article: 7246 of comp.editors
Newsgroups: comp.editors
Path: alf.uib.no!trane.uninett.no!sunic!pipex!uunet!usc!sdd.hp.com!col.hp.com!csn!boulder!ucsu!spot.Colorado.EDU!siffert
From: siffert@spot.Colorado.EDU (Thunder-Thumbs)
Subject: Re: VIM: Does it provide :ab[breviate] command ?
Message-ID: <1993Jul11.082004.9176@ucsu.Colorado.EDU>
Sender: news@ucsu.Colorado.EDU (USENET News System)
Nntp-Posting-Host: spot.colorado.edu
Organization: Thunder-Thumbs, Inc.
References: <1993Jul9.095130.8521@philce.ce.philips.nl>
Date: Sun, 11 Jul 1993 08:20:04 GMT
Lines: 23
i323856@indus.cad-sg.ce.philips.nl ( DEWENDRA SHASTRI ) scribes:
>
>Hi Netters,
>I am having a problem in switching from standarad vi to Vi iMitation (VIM)
>editor. I have lots of abbreaviations in .exrc file, vim cribs about them as
>"Invalid command". I did not find any referrence to this problem in the
>reference.doc supplied with the editor. Moreover differences.doc also
>doesnot talk about this. If any body has any information about this, it
>will be nice.
>Thanx in advans
>Devendra Shastri (i323856@cad-sg.ce.philips.nl)
The abbreviate command counts as an Ex command, which isn't supported
fully in VIM. I got around this by remapping my abbr stuff to escape
key sequences. It's not a big deal.
Incidentally, I didn't even realize that capability until recently.
In escape mode (both vi and vim), you can map something like esc-s
and it's a valid command if you do it fast enough. No wonder there's
that one-second lag before vi beeps at you on a double-escape... it's
making sure it's not a real command! pretty nifty.
Curt (siffert@spot.colorado.edu)
From alf.uib.no!trane.uninett.no!sunic!uunet!news.cnri.reston.va.us!newsserver.jvnc.net!howland.reston.ans.net!math.ohio-state.edu!cs.utexas.edu!csc.ti.com!tilde.csc.ti.com!ra.csc.ti.com!process!frc Wed Jul 21 10:10:25 MET DST 1993
Article: 7324 of comp.editors
Newsgroups: comp.editors
Path: alf.uib.no!trane.uninett.no!sunic!uunet!news.cnri.reston.va.us!newsserver.jvnc.net!howland.reston.ans.net!math.ohio-state.edu!cs.utexas.edu!csc.ti.com!tilde.csc.ti.com!ra.csc.ti.com!process!frc
From: frc@process (Robert Colon)
Subject: Re: VIM:Does it provide :ab[breviate] command ?
Message-ID: <CA24rF.9nr@csc.ti.com>
Sender: usenet@csc.ti.com
Nntp-Posting-Host: process.dadd.ti.com
Organization: Texas Instruments
X-Newsreader: TIN [version 1.1 PL9]
References: <21kpa9INNqa6@darkstar.UCSC.EDU>
Distribution: inet
Date: Mon, 12 Jul 1993 15:09:15 GMT
Lines: 37
> In <1993Jul9.095130.8521@philce.ce.philips.nl> i323856@indus.cad-sg.ce.philips.nl ( DEWENDRA SHASTRI ) writes:
> >Hi Netters,
> >I am having a problem in switching from standarad vi to Vi iMitation (VIM)
> >editor. I have lots of abbreaviations in .exrc file, vim cribs about them as
> It doesn't seem to be there, at least in 1.27. I was somewhat annoyed
> too, maybe :ab will be in a future version. On the other hand, the extra
> features have convinced me to donate a significant portion of my quota to
> vim + docs, even though this system as a perfectly good "real" vi. As
> long as I'm not connected at speeds below 9600 baud, I can live w/o ":ab"
> As a temporary measure, a :map! might help you out...
> --
> Maurice S. Barnum --- I consult, therefore I am:
> msb@cats.ucsc.edu, mbarnum@eis.calstate.edu, mbarnum@nyx.cs.du.edu
vim version 1.28, which is now in beta, definitely supports :ab along with
some other nice new features like a toggle between line wrap and horizontal
scrolling. I too have switched from using commercial vi (which is going
nowhere) to vim. vim has enough new extensions (cut/paste [including by
columns] indicated by reverse video, multi-level undo/redo, ability to edit
long lines and binary files, etc.), handles all my complex macros, fixes
several vi annoyances, and is robust enough that I have adopted it as my
standard editor. Plus, if one is not aware of the new features, vim works
"just like vi". PLUS, one has the source code! As importantly, the author,
Bram Moolenaar, has been quite responsive to users reporting bugs and
requesting new features. (Ever try doing that with vi?)
The 1.28 version probably won't be available for a few months yet but will be
worth the wait.
--
Robert Colon EMAIL: frc@dadd.ti.com
Texas Instruments, Inc. MSGID: FRC
Design Automation Division MS 3937 PHONE: 214/917-3644
P.O. Box 650311 Dallas, Tx 75265 FAX: 214/917-7966
From alf.uib.no!trane.uninett.no!sunic!uunet!europa.eng.gtefsd.com!howland.reston.ans.net!agate!darkstar.UCSC.EDU!cats.ucsc.edu!msb Wed Jul 21 10:11:07 MET DST 1993
Article: 7326 of comp.editors
Path: alf.uib.no!trane.uninett.no!sunic!uunet!europa.eng.gtefsd.com!howland.reston.ans.net!agate!darkstar.UCSC.EDU!cats.ucsc.edu!msb
From: msb@cats.ucsc.edu (Maurice S Barnum)
Newsgroups: comp.editors
Subject: Re: VIM:Does it provide :ab[breviate] command ?
Date: 21 Jul 1993 00:12:07 GMT
Organization: University of California, Santa Cruz
Lines: 28
Distribution: inet
Message-ID: <22i1knINN3g1@darkstar.UCSC.EDU>
References: <21kpa9INNqa6@darkstar.UCSC.EDU> <CA24rF.9nr@csc.ti.com>
NNTP-Posting-Host: am.ucsc.edu
In <CA24rF.9nr@csc.ti.com> frc@process (Robert Colon) writes:
>standard editor. Plus, if one is not aware of the new features, vim works
>"just like vi". PLUS, one has the source code! As importantly, the author,
>Bram Moolenaar, has been quite responsive to users reporting bugs and
>requesting new features. (Ever try doing that with vi?)
A few things about vim that are NOT "just like vi":
o screen refresh is abysmally slow. Too much text is being moved around
in cases where a line scroll would be sufficient.
o there is no :set redraw, which I find essential on slow connections,
even more so with vim than with vi. :(
o vim doesn't deal well with tvi-type terminals. ^H and ^K get
interpreted as arrow movements. I don't know if this is a termcap
problem, or a vim problem, but vi and everyting else works just fine.
hrm. I would have sent them in as bug reports, but didn't know where.
--
Maurice S. Barnum The errors of great men are venerable
msb@cats.ucsc.edu becauxse they are more fruitful than
mbarnum@eis.calstate.edu the truths of little men....
mbarnum@nyx.cs.du.edu --- F. Nietzsche

419
comp.editors/vs.emacs Normal file
View File

@ -0,0 +1,419 @@
From: jim@blade.stack.urc.tue.nl (Jim Rump)
Newsgroups: comp.unix.misc
Subject: Vi vs EMACS ans C-editing
Date: 23 Mar 92 21:51:08 GMT
Sender: news@tuegate.tue.nl
Organization: MCGV Stack, Eindhoven University of Technology, the Netherlands.
Lines: 408
Status: RO
Hello all,
recently I posted something about wheter to use VI or EMACS for c-source
editing. This resulted in some interesting reactions. This is a summery.
If you edit a lot of c-code then this is something for you to read. It
mostly gives objective opinios.
(1) from: Rich
I am someone who used to be a vi-head. I decided to bite the bullet and
learn emacs, and I love it. I actually use epoch which is an X windows
version of emacs. This is one advantage over vi. It is an X program
rather than an xterm running vi.
The main reason I learned emacs is because the choice of using emacs or
vi is not an either/or type of a choice. The real question is:
Do I want to know 2 editors or am I happy just knowing one?
I decided that learning emacs was a good idea because then I would
would be more knowledgeable regardless of which editor I eventually decided
I liked better. I am better at my job because I know both vi
and emacs whereas all of the vi people only know vi.
The main advantage of knowing both editors is that they each are better
for various things. I generally use vi for any quick edits I am going
to make. I also use it when I have to perform the same changes on a list
of files. The ":n" command works wonderfully for this. I generally use emacs
when I am sitting down and doing long coding sessions. One great thing
about emacs is that it buffers up all of your files and you can very easily
switch between several files. Another execellent feature is the undo
facility which will usually allow you to undo every single change to
a specific file 1 by 1. Emacs has several other great features but I
won't go into any more of them.
In conclusion, you will never forget how to use vi, and you will
always need to use it for somethings. (ie. bringing up a new O.S. or
compiling emacs). The real question you should be asking yourself is
whether or not you want to learn a second editor. The question should never
be "emacs or vi?"; the question should always be "vi or (emacs and vi)?"
I believe that the answer to this question is obvious: the more you know, the
better off you are. You should realize that most emacs people know vi, whereas
the reverse is not true. I think this is because most people that have the
patience to learn emacs decide they like it better, and they don't switch
back to vi.
-rich
P.S. If you really do only want to know one editor, then I think the
choice has to be vi because this is what comes bundled with most
operating systems.
******************************************************************************
(2) from: ahcc!ebenv@uunet.UU.NET (eben)
I like vi. I used it for years, and my fingers can do anything in
their sleep, from editing multiple files to sorting a range to writing
a macro.
So, when one day a colleague brought in a copy of emacs (this was
several years ago), I thought, "Great! Now we're going to have THREE
way religious wars!" (we had one vocal "j" user).
Instead, miraculously, everyone switched to emacs. Even me, who had
sworn a life of love and allegiance to vi.
I can still vi happily when need be. But when emacs is available, I
am more productive. I always have several shells around, have an
interactive sql session in a buffer, have lots of files in buffers,
and read and write mail in an integrated way. If you're stuck on an
antique dumb ascii terminal, rather than at a real terminal (an X
workstation), it gives you windowing, multiple shells, and many of the
things that are productive about a modern GUI.
Over the 7 years since I met emacs, I've helped quite a few colleagues
to consider it. Without exception, they've stayed switched, and many
have come raving back to me months later wondering how they ever lived
without it.
It's like unix--it's advantages over dos perhaps aren't visible in
your first day or week or month. But as you grow, you come to be more
productive and less frustrated. Good luck.
--
Eben
******************************************************************************
(3) from: James E. Leinweiber.
In the interests of avoiding yet another outbreak of the dreaded
editor flame wars (editor preferences are intensely personal, and all too
often dictated by whatever one learned first), allow me to offer the
following teaser document. I was trying to lure vi users to try
emacs, without much success, but we have only 3-4 programmers in my
organization, so I'm not heartbroken. Ignore all the references to
local customizations. I use both vi and emacs every day, learned vi
first, and greatly prefer emacs. Caveat Lector!
James Leinweber State Laboratory of Hygiene/Univ. of Wisconsin-Madison
jiml@slh.wisc.edu uunet!uwvax!uwslh!jiml +1-608-262-0736
-----------------------------------------------------------------------------
Emacs versus Vi
Emacs is yet another text editor, which is older, larger and more
sophisticated than Vi. To learn to use it you should get a copy of the
quick reference guide and do the on-line tutorial. You may run the
tutorial by "emacs", 'backspace' 't'. In case of problems, abort
commands with '^G' and exit emacs by 'C-x' 'C-c'. (You may be asked
about saving buffers; just type 'n' or "no" 'RET' when you are
prompted for a response at the bottom of the screen.)
Roughly speaking, Vi is superior for line-oriented editing, while
Emacs is better for other kinds of editing. For editing program text
it may be a toss-up, but Emacs can also edit odd files (binary, empty,
very long lines, ...) and is definitely superior for entering new
text. The main functional differences between Emacs and Vi are that
Emacs supports multiple window editing, horizontal scrolling, is fully
programmable, and has on-line help. However, only Vi will show line
numbers on the screen. (Vi is a screen interface to a line-oriented
editor; Emacs is not.)
The feel of the two editors is very different. In Vi you are always
switching modes in order to give commands and enter text; in Emacs
text is self-inserting and commands are activated by a plethora of
control character sequences, using both the control and meta or Escape
keys. Vi has a larger repertoire of cursor motion commands, a handful
of operators, and short command sequences. Emacs relies more on
arguments to commands, and on applying commands to regions of text.
Many commands in Emacs are similar to using Vi commands with marks.
Both editors understand indenting, filling, and abbreviating text,
although Emacs is better at these. Both allow named locations and
named buffers or registers for chunks of yanked or deleted text. Vi
is more convenient for some things, such as ":g/pattern/m$", which are
not directly built into Emacs. Emacs has nice commands such as "C-t"
to switch the last two characters, and "M-- M-c" to capitalize the
previous word. Undo is much better in Emacs, as are macros.
For basic editing, using the two dozen or so most common commands, Vi
and Emacs are quite comparable in difficulty of learning and ease of
use. Since emacs has more concepts than Vi, about four times as many
commands, and a complete Lisp programming language built in, it is
significantly harder to master. Intermediate users may find that the
on-line help in Emacs outweighs the additional complexity. The extra
functionality in Emacs comes at a price: it plus its documentation use
large amounts of memory and disk, and it uses slightly more CPU time
than Vi.
Learning Emacs
The easiest way to learn emacs is just to type "emacs", and follow the
tutorial directions. After the tutorial you will know enought to
use emacs. Next you should study a quick reference card for about 20
minutes, trying out some of the commands. Don't hesitate to use the
on-line help, and remember that you can undo mistakes regardless of
how many commands you have used in the meantime. It took me about a
week to get confortable using emacs and stop referring constantly to
the reference card, and it was worth it. Features of Emacs not found
in Vi and worth investigating include: windows, incremental search,
keyboard macros, recursive edits (particularly from query-replace),
narrow versus wide bounds, and shell mode.
Quirks
Emacs expects to use C-g for interrupt, C-h for help, and DEL for
erase character, which conflicts with the standard SLH keyboard
conventions. You have three choices: live with the difference, give in
to emacs and put 'stty dec' in your .login file, or have me remap
your emacs keyboard (I use C-h for character erase, DEL for interrupt,
and C-g for help.). All three have annonying features, namely
cognitive dissonance, incompatibility with co-workers and the 1100, or
disagreements with the emacs manual. (E.g., references to C-x DEL
must be translated to C-X C-h). Start by trying plain emacs, and let
me know which you eventually decide on.
The TAB key behaves unusually in Emacs: in indenting modes it restores
the indent of the current line, rather than inserting a TAB. In the
minibuffer it does command and filename completion, along with space
and CR. To insert one, use M-i or quote it (C-q C-i).
Your emacs startup file is called ~/.emacs, and is written in Lisp. I
have provided a self-installing one to get things started. There are
a few differences from the documentation, which I will describe.
First, the default mode is "indented-text" rather than "fundamental".
Furthermore, a comment character "#" is defined, so it should be very
easy to edit shell scripts. You can turn off the indenting with "M-x
text-mode RET". You can toggle auto-fill with "M-x auto-fill RET".
Mail mode will turn on auto-fill for you. C-mode will use the usual
Unix indenting style, rather than the default Gnu style. Personally,
I prefer the Gnu style (see /usr/src/local/screendump.c for an example).
On an HDS terminal, the arrow, scroll and page keys will work, but not
on other types. As a side effect, the paragraph motion commands have
been moved from M-[ and M-] to M-{ and M-}. By the way, the Meta key
on the HDS terminals works; otherwise type M-{ etc. as "ESC {". On
other kinds of terminals, you will have to do this.
Emacs prefers to run on terminals with flow control turned off, so
that C-s and C-q can be used as command characters. For this reason,
it uses alternate termcap entries that delay after slow operations.
Let me know if you have any problems with screen updating, as these
are usually caused by insufficient padding.
CR and LF are changed: CR always indents and LF never does. Finally,
C-o (open-line) is modified to insert the current fill prefix. The fill
prefix is set by "C-x ." to the text before the cursor, and cancelled
by "C-a C-x ." (setting it at the beginning of a line).
******************************************************************************
(4) from : Glen Larsen
I use both vi and emacs. If you're going to be on a u*ix system,
you're going to have to know vi. You can't beat it for quick edits
and those times that you aren't in your cozy little emacs environment.
For me, emacs is a productivity tool for coding. It indents as I
write, I can change styles easily (or reformat somebody elses code so
I can view it the way I like it), and writing comments is a breeze.
Compilations are done with a single keystroke, if there are any errors
a single key sequence can get me to that line of code (and pull in the
file into another buffer if necessary). I can run shell commands on a
region or whole buffer. I have RCS commands bound to keys and the
dired (directory editing) mode so that I can check revisions out and
in (*and* write the commentary in an editor buffer). Also, I like
multi-buffer editing and writing lisp macros.
Emacs is a different mindset. I'm sure your friends have shown you
how great emacs is, and what it can do that vi can't, you better be
prepared to hear that vi can do some things that emacs can't. Don't
let anyone tell you that it will make you a better software engineer.
For me, vi has become another unix tool just like sed & awk --- great to
have around for those odd moments. Do what fits your style, but I
think you would be doing yourself a disservice if you don't learn
emacs sufficiently enough to see if it fits that style.
- glen
--
Glen Larsen glenl@hadar.fai.com
Fujitsu Network Transmission Systems (408)456-7890
Software Technology Group, San Jose, CA, USA 95134
(5) from: Jim Thompson
I have been a unix programmer for the last four years, and for the first
three I used vi. I always had people telling me what a great editor
emacs was, and how I ought to be using it because it was so great. But
vi was doing the job just fine for me, and besides, every time I used
emacs, I couldn't figure out how to do *anything*, because of all those
complicated control sequences.
When I started a new job about a year ago, I decided I would bite the
bullet, and learn emacs no matter how hard and frustrating it was. It
took me about a month to be able to use emacs effectively, and another
six or so before I was able to program lisp well enough to really
customize it. But it was well worth; I'm noticably more productive
using emacs than I was using vi.
Your friends were right; for editing C code, emacs is fantastic--far
superior to vi. About the only support vi has for editing code are
auto-indent and the shift commands. Emacs, on the other hand, has a
"major mode" for editing C code, and it makes the job much easier.
It's most effective when you're entering new code. As you type in the
code, emacs will automatically adjust the indentation levels to match
the nesting of the C control structures such as for-loops and if-
statements. Emacs will also automatically match paired characters for
you, such as (, ), {, }, [, ], to help cut down on syntax errors.
Emacs is also better at entering long comments; it can automatically
break long comments and reindent them so they line up with the first
comment line. You just type the words, no matter how many; emacs does
the rest for you. Emacs also handles end-of-line comments well; you
can type M-; and the cursor will jump past the end of the line to a
predefined comment column and enter the comment-start characters.
My best advice for you, should you choose to learn emacs, is to get a
book and read it first; it will help you greatly to know something about
emacs before you start trying to learn it.
Good luck!
Jim
--
_ Jim Thompson | Western Geophysical
| ~- thompson@wg2.waii.com | Exploration Products
\, _} jimt@sugar.neosoft.com | 3600 Briarpark
\( (713) 964-6213 | Houston, TX 77042
******************************************************************************
(5) from: Gwyn Evans
I find that GNU Emacs very useful for me when C coding as I like it's
options of auto-indent, auto-newline on ';','{' and '}'. All configurable
to match your required coding style, of course!
I find that it's also very useful being able to have a number of files
open at the same time and to be able to have multiple windows on the screen.
It's best if you have a workstation :-) as you can have a large emacs
window but even on a tty, I find that I use vi for some quick edits but
for more than a couple of lines, I use emacs and then shell out of that
it I need to get to a cli.
Another useful point is that it's got built-in help, which I found
very useful when starting. It also have a vi mode, although I don't
know if this has any ':' options as opposed to just the i,r,x,cw, etc
commands.
Gwyn
--
+======================================================================+
| Gwyn Evans | evansg@uproar.enet.dec.com | Uxbridge, Middlesex, UK |
| DESISCo - Digital Equipment Service Industries Solutions Company Ltd |
| Views expressed and statements made are mine and not those of DEC |
+======================================================================+
******************************************************************************
(6) from: Eric Wang
No contest. I was a vi power-user for two years, and find emacs to be
infinitely more powerful, especially for moderately large, nicely
modularized C (and Lisp and ksh) applications. In fact, I bet I can
make you switch with just one sentence:
Emacs can edit multiple files on the screen simultaneously. vi can't.
emacs will let you split your screen into 2 (or more) windows and look
at any 2 (or more) files simultaneously (or the same one in two places).
You can jump back and forth between windows. You can cut and paste
between them. They scroll separately.
vi can maintain multiple files in memory, but it can display only one at
a time, and you MUST save or discard ALL your changes to it before vi
lets you switch to another one.
I find that this one distinction between the two is one of the most
significant from a programmer's standpoint. If you have a moderately
large project of ~10 .c files and ~5 .h files, you will often want to
look at a .h file in one window while you edit a .c file in another
window. In emacs, this is EASY. In vi, it's IMPOSSIBLE. End of case!
:-)
(There are, of course, many more reasons to prefer emacs over vi.
Basically, whatever vi can do, emacs can do better. The *only*
advantage vi really has over emacs is that it's small, so it takes much
less memory and starts up more quickly. But then, the average tricycle
is smaller than the average car, too.)
Eric Wang
wang@ibma0.cs.uiuc.edu
******************************************************************************
(7)from: Nick Vargish
I just switched to Emacs from vi myself... Emacs takes a while to get
used to (especially after vi), but you'll really like the difference. The
biggest selling point for me was that emacs is a mostly-modeless,
which means one moves, inserts, deletes, without having to switch
modes -- you know, like REAL text editors.
vi is, after all, just a full-screen display grafted onto a line-based
editor. You'll see this more clearly if you try emacs for a couple of
days in your editing routine.
Emacs can be daunting, but there are some good books out there on it,
and the time you invest in learning Emacs will be well rewarded...
--
Nick Vargish
SURAnet Operations
vargish@sura.net
******************************************************************************
(8)from: Linus Tolke
What I believe is:
If you like to start an editor for every file then vi is *much*
faster. This is the only thing I find in favor of vi.
Emacs is best used as an entire environment. You have all the files
you are editing within emacs, do the compilation within emacs, running
and debugging from within emacs.
--
/Linus
***** Wherever I exec my `which emacs`, is my $HOME. *****
Linus Tolke SM7OUU, linus@lysator.liu.se
Student at the member of SK5EU LiTHSA
Link|ping institute of technology, LiTH LiTH S{ndare Amat|rer (Ham-club)
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Jim Rump % E-mail: %
% Eindhoven % jim@stack.urc.tue.nl %
% Netherlands % (TU-Eindhoven) %

33
comp.editors/windowrez Normal file
View File

@ -0,0 +1,33 @@
From skf26@cas.org (Scott Frost)
Subject: Vi handling window resizing, how?
Date: Tue, 11 Aug 1992 11:59:44 GMT
Currently, on my SunOS 4.2 version of VI, I have to do the following
after I resize a window in which vi is running to get it to recognize the
new window size,
Qset term=xterm^Mvi^M
I've tried mapping this to a macro,
but once the Q key is hit to leave VI, the rest of the macro is ignored.
Is there any way around this?
--
Scott K. Frost UUCP: osu-cis!chemabs!skf26
Same Mbox: BITNET: skf26@cas INET: skf26%cas.BITNET@CUNYVM.CUNY.Edu
Personal: 2753 Shrewsbury Rd, Upper Arlington Oh 43221
From skf26@cas.org (Scott Frost)
Subject: Resizing VI - Trying again
Date: Fri, 14 Aug 1992 12:23:55 GMT
Earlier I posted an inquiry about how to create a macro to perform the
following,
Qset term=xterm^Mvi^M
The vi on SUN 0S 4.1.2 does not recognize a window resize. Quitting vi,
resetting the term, and reinvoking vi works. The problem is that I can't
seem to map a macro to per

76
comp.editors/wordwrap Normal file
View File

@ -0,0 +1,76 @@
From stokesj@gordon-emh3.army.mil ( SFC John Stokes)
Subject: vi wordwrap
Date: 2 Jun 92 23:09:17 GMT
Does any one have a suggestion as to how to rewrap a paragraph
in vi? Here is a line I have in my .exrc that does the current
line. Is there a way to extend this to continue down each line
until it gets to a blank line? One flaw in this definition is
the last word of the last line always wraps to the next line.
map ^W J070lF r^M
(Note I used the carot (^) symbol here to indicate Control
characters, which had to be quoted when entered.)
______
/
/ __ /_ __
___/ /_/ / / / / Stokes
From damrau@sscux1.ssc.gov (Jackie Damrau)
Subject: Re: vi wordwrap
Date: Wed, 3 Jun 1992 13:20:37 GMT
In article <30759@adm.brl.mil> stokesj@gordon-emh3.army.mil ( SFC John Stokes) writes:
>Does any one have a suggestion as to how to rewrap a paragraph
>in vi? Here is a line I have in my .exrc that does the current
>line. Is there a way to extend this to continue down each line
>until it gets to a blank line? One flaw in this definition is
>the last word of the last line always wraps to the next line.
>
>map ^W J070lF r^M
>
>(Note I used the carot (^) symbol here to indicate Control
>characters, which had to be quoted when entered.)
> ______
> /
> / __ /_ __
> ___/ /_/ / / / / Stokes
To format a paragraph within vi, I have used:
{!}fmt where "fmt" is the UNIX command that does what you want (e.g.,
J).
--
Jackie Damrau, SSC Laboratory
Computer Operations Group, MS-1011,
2550 Beckleymeade Avenue, Dallas TX
Internet: damrau@sscvx1.ssc.gov
From tchrist@convex.COM (Tom Christiansen)
Subject: Re: vi wordwFrom mchinni@pica.army.mil (Michael J. Chinni, (SMCAR-CCS-W))
Subject: Re: vi wordwrap
Date: 3 Jun 92 19:12:06 GMT
John you wrote:
> Does any one have a suggestion as to how to rewrap a paragraph
> in vi? Here is a line I have in my .exrc that does the current
> line. Is there a way to extend this to continue down each line
> until it gets to a blank line? One flaw in this definition is
> the last word of the last line always wraps to the next line.
> map ^W J070lF r^M
If your system has some BSD utilities, you can use "fmt". Quoting from the
"man" page for "fmt":
SYNOPSIS
fmt [ -width ] [ name ... ]
DESCRIPTION
Fmt is a simple text formatter that reads the concatenation
of input files (or standard input if none are given) and
produces on standard output a version of its input with
lines as close to 72 characters long as possible. Default
line width can be altered with the -width option. The
spacing at the beginning of the input lines is preserved in
the ou

92
comp.editors/writeout Normal file
View File

@ -0,0 +1,92 @@
From alex@am.sublink.org (Alex Martelli)
Subject: Re: Writing out a section of a file to another file with vi ???
Date: 28 Sep 92 22:14:35 GMT
mpalmer@encore.com (Mike Palmer) writes:
:>What's the easiest way to write out a "block" of lines to another file,
:>without having to count the lines, or find the first line number and the
:>last? What I'd really like to do is dump a named buffer to disk:
:>mx
:>y'x
:>write x to disk
Once you have yanked to the *named* buffer, :e the file you want
to write it into, and just put it. NAMED buffers are remembered
by vi; it's only the UNNAMED one which is lost when switching files.
You will have to :w the current file before :e to the new one if
there were any changes (unless you :set autowrite, or are willing
to lose the changes).
Alternatively, if you want to write to disk file pip from the
current line to mark x, just :.,'x w pip...
I suggest that any followup be to comp.editors, as a more appropriate
newsgroup than comp.unix.anything would be.
--
Alex Martelli - alex@am.sublink.org - +39 (51) 250434 - Bologna, Italia
From rouben@math9.math.umbc.edu (Rouben Rostamian)
Subject: Re: Writing a "block" of lines to another file
Date: Sat, 26 Sep 1992 12:41:44 GMT
In article <Bv6n4M.Dox@encore.com> mpalmer@encore.com (Mike Palmer) writes:
>I'd like to be able to write a "block" of lines to a file, without having to
>count the lines, or get the start & end loine number. Can I use the temp
>buffers something like:
>
>mx
>y'x
>write x to file
Almost right. Mark the first line of the block, say, mx. Move to
the last line of the block and do any of:
:'x,.w file [if writing to a new file]
or
:'x,.w! file [if re-writing an existing file]
or
:'x,.w >> file [if appending to an existing file]
as necessary.
--
From yan@integ.frec.bull.fr (Yves A. Nicollet)
Subject: Re: Writing a "block" of lines to another file
Date: 5 Oct 92 12:13:42 GMT
Reply-To: Y.A.Nicollet@frec.bull.fr
In article <1992Sep26.124144.6699@umbc3.umbc.edu>, rouben@math9.math.umbc.edu (Rouben Rostamian) writes:
>In article <Bv6n4M.Dox@encore.com> mpalmer@encore.com (Mike Palmer) writes:
>>I'd like to be able to write a "block" of lines to a file, without having to
>>count the lines, or get the start & end loine number. Can I use the temp
>>buffers something like:
>>
>>mx
>>y'x
>>write x to file
>
>Almost right. Mark the first line of the block, say, mx. Move to
>the last line of the block and do any of:
>:'x,.w file [if writing to a new file]
>or
>:'x,.w! file [if re-writing an existing file]
>or
>:'x,.w >> file [if appending to an existing file]
>as necessary.
And if you wanted to move lines from a file to another file you would like
then to edit, you could:
go to the 1st line and type
mx [to mark the beginning of the block]
go to the last line and type
"xy'x [to yank from the mark x till the current line into buffer x]
go to the other file by typing
:e# (or :e file)
go to where you want to put the block and type
"xp

43
comp.editors2 Normal file
View File

@ -0,0 +1,43 @@
Newsgroups: comp.editors
Subject: Not a regular request for vi-related files.
Followup-To: Poster
Reply-To: Ruben@Uib.no
Organization: University of Bergen, Norway
Keywords: vi-stuff, archives, anon ftp.
Summary: vi
Distribution: comp
Regularity: Whenever I feel for it.
BEWARE: mapping of ^D
[To the comp.archives maintainers: Please do not archive this]
This is a iregular request on EX/VI-related stuff for inclusion in the
VI-archives around the world.
If you have stuff like tutorials, macros, tips, trics et.al about VI,
please mail them to Ruben@uib.no for inclusion in the VI-archives
A index of the archives contents is posted in the end/begining of each
month to this newsgroup.
And a thank you to all of you who have submitted information, macros et.al
to the archive. :-)
VI/EX archives are to be found on the following anon ftp sites:
alf.uib.no (129.177.30.3), PEEK: 0700 am GMT - 0300 pm GMT
utsun.s.u-tokyo.ac.jp (133.11.11.11) PEEK: 0100 am GMT - 0900 am GMT
cs.uwp.edu (131.210.1.4), PEEK: NONE
monu6.cc.monash.edu.au (130.194.1.106) PEAK: NOT RELEVENT
Please use the site wich is nearest your site net.vise. If you are not
sure of what I'm talking about, please ask someone who knows. This is
among others, your system manager.
It's also possible to access the archives for those without ftp access.
Send a mail to Ruben@Uib.no with HELP as subject.
Regards,
\Ruben

41
comp.editors3 Normal file
View File

@ -0,0 +1,41 @@
[... Old Article Quoting goes here ...]
From one of the INDEX files at the VI/EX archives around the world:
[... Flielist ...]
The VI/EX archives can be found at:
Europe:
Main site: alf.uib.no (129.177.30.3)
Filearea: pub/vi
Peak hours: 07.00 am GMT to 03.00 pm GMT
Japan:
Mirror site: utsun.s.u-tokyo.ac.jp (133.11.11.11)
Filearea: misc/vi-archive
Peak hours: 01.00 am GMT to 09.00 am GMT
USA, Canada and Mexico:
Mirror site: cs.uwp.edu (131.210.1.4)
Filearea: /pub/vi
Peak hours: None.
Mirror site: ftp.uu.net (192.48.96.9)
Filearea: /pub/text-processing/vi
Peak hours: None.
Australia, NZ and the rest Down Under:
Main site: monu6.cc.monash.edu.au (130.194.1.106)
Filearea: /pub/Vi
Peak hours: Not relevent
For more information about the files in the archives fetch the INDEX file.
If you need more information, you are welcome to mail Ruben@uib.no.
\Ruben.

BIN
docs/132.Z Normal file
View File

Binary file not shown.

BIN
docs/POINTERS.Z Normal file
View File

Binary file not shown.

BIN
docs/advocasy.Z Normal file
View File

Binary file not shown.

BIN
docs/apwh.ms.Z Normal file
View File

Binary file not shown.

121
docs/arrowkwys Normal file
View File

@ -0,0 +1,121 @@
From simonm@koel.mel.dit.CSIRO.AU (Simon McClenahan)
From: simonm@koel.mel.dit.CSIRO.AU (Simon McClenahan)
Newsgroups: comp.sys.sgi.bugs,comp.editors
Subject: Re: FAQ Alert: Mode Change for Pressing Arrow Keys in vi editor
Date: Tue, 14 Dec 93 03:58:28 GMT
Organization: CSIRO DIT (Melb.)
Lines: 39
In <1993Dec12.010048.23782@brl.mil> "RANDOLPH J. HERBER, HERBER@FNALA.FNAL.GOV, +1 708 840 2966, CD/HQ - CDF" <HERBER@fnalv.fnal.gov> writes:
> > From: Jia-Yu Chiu <jychiu@cscs.ch>
>
> > I have this problem only on SGI machine. Other machines like
> > SUN are alright.
>
> > When I edit a file with 'vi' editor under xterm environment,
> > the edit mode quickly change from one to another when I press
> > the up/down/right/left arrow keys to move a few places.
> > (eg down key generates a 'B' character). It is very annoying as
> > I have to hit the 'esc' key to change mode frequently.
>
> > Is it a bug or environment setting ?
> When using the vi editor over a network of any kind or speed, keep your
> fingers off of the arrow keys! Use the h, j, k, and l keys instead.
[explanation of why this happens, deleted]
Try putting this in your .exrc file
map! ^[OA ^[ka
map! ^[OB ^[ja
map! ^[OC ^[la
map! ^[OD ^[ha
Where ^[ is the Esape character (^V Escape)
Anyone else have any handy hints like this?
cheers,
--
Simon.McClenahan@mel.dit.csiro.au ::::: CSIRO Supercomputing Support Group
CSIRO Division of Information Technology ::::::::::::: tel: +61 3 282 2623
723 Swanston St, Carlton 3053 AUSTRALIA :::::::::::::: fax: +61 3 282 2600
Why is "abbreviated" such a long word?
From Paul.Terray,,F426,,5-2@aedi.insa-lyon.fr (Paul Terray)
From: Paul.Terray,,F426,,5-2@aedi.insa-lyon.fr (Paul Terray)
Newsgroups: comp.sys.sgi.bugs,comp.editors
Subject: Re: FAQ Alert: Mode Change for Pressing Arrow Keys in vi editor
Date: 14 Dec 1993 10:48:44 GMT
Organization: INSA Lyon - Computer Science Dept / France
Lines: 14
Sometimes, when you are in command mode, you will notice that
arrow key insert 'B', or 'C', or other letters. It comes from the
fact that your arrow keys give the sequence ^[OA (or B,C,D), but
too slowly to be understood. Try to set the timeout variable:
:set notimeout (or :set noto)
You will notice that when you press Esc key after that, vi
doesn't switch immediatly. You just have to keep on typing, so vi
see that you are not using arrow keys.
Paul TERRAY
popaul@aedi.insa-lyon.fr
From sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins)
From: sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins)
Newsgroups: comp.sys.sgi.bugs,comp.editors
Subject: Re: FAQ Alert: Mode Change for Pressing Arrow Keys in vi editor
Date: Wed, 15 Dec 1993 14:46:47 GMT
Organization: Computer Science Dept., Ohio University, Athen Oh.
Lines: 41
In article <1993Dec14.035828.15600@mel.dit.csiro.au> Simon.McClenahan@mel.dit.CSIRO.AU writes:
>In <1993Dec12.010048.23782@brl.mil> "RANDOLPH J. HERBER, HERBER@FNALA.FNAL.GOV, +1 708 840 2966, CD/HQ - CDF" <HERBER@fnalv.fnal.gov> writes:
>
>> > From: Jia-Yu Chiu <jychiu@cscs.ch>
>>
>> > I have this problem only on SGI machine. Other machines like
>> > SUN are alright.
>>
>> > When I edit a file with 'vi' editor under xterm environment,
>> > the edit mode quickly change from one to another when I press
>> > the up/down/right/left arrow keys to move a few places.
>> > (eg down key generates a 'B' character). It is very annoying as
>> > I have to hit the 'esc' key to change mode frequently.
>>
>> > Is it a bug or environment setting ?
>
>
>> When using the vi editor over a network of any kind or speed, keep your
>> fingers off of the arrow keys! Use the h, j, k, and l keys instead.
>
>[explanation of why this happens, deleted]
>
>Try putting this in your .exrc file
>
>map! ^[OA ^[ka
>map! ^[OB ^[ja
>map! ^[OC ^[la
>map! ^[OD ^[ha
Also, put in a similar set of lines for other types of terminals:
map! ^[[A ^[ka
map! ^[[B ^[ja
map! ^[[C ^[la
map! ^[[D ^[ha
Scott.
--
Scott W. Adkins Internet: sadkins@ohiou.edu
~~~~~~~~~~~~~~~ ak323@cleveland.freenet.edu
Ohio University of Athens Bitnet: adkins@ouaccvma.bitnet

BIN
docs/bed.tar.Z Normal file
View File

Binary file not shown.

BIN
docs/beginers.Z Normal file
View File

Binary file not shown.

BIN
docs/books.Z Normal file
View File

Binary file not shown.

BIN
docs/bugs.Z Normal file
View File

Binary file not shown.

BIN
docs/capitalize.Z Normal file
View File

Binary file not shown.

BIN
docs/card.tex.Z Normal file
View File

Binary file not shown.

68
docs/caseconv Normal file
View File

@ -0,0 +1,68 @@
From prasad@cmie.ernet.in (Prasad Khurd)
Subject: Help ! - Converting Proper case to Upper case in Vi.
Date: Thu, 3 Jun 1993 11:51:58 GMT
Hi there
i read of a way to convert ALL upper case letters to lower case in the
file in VI in one shot (not using ~ which works per charater) on the
net somewhere but forgot it. i shall be very grateful if someone mails
me how to do that.
thanx
Prasad Khurd.
______________________________________________________________________________
prasad@cmie.ernet.in
Centre for Monitoring Indian Economy, Bombay.
______________________________________________________________________________
From edwin@integow.integrity.nl (Edwin Koedam)
Subject: Re: Help ! - Converting Proper case to Upper case in Vi.
Date: 4 Jun 93 06:52:47 GMT
Prasad Khurd writes:
> Hi there
>
> i read of a way to convert ALL upper case letters to lower case in the
> file in VI in one shot (not using ~ which works per charater) on the
> net somewhere but forgot it. i shall be very grateful if someone mails
> me how to do that.
>
You should use:
:%s/./\u&/g
Hope this helps,
Edwin.
--
UUCP: ..!uunet!mcsun!sun4nl!integow!edwin or INTERNET: edwin@integrity.nl
Edwin Koedam, software engineer, Integrity software consultants,
Pelmolenlaan 2, 3447 GW Woerden, The Netherlands.
tel +31 3480 30131, fax +31 3480 30182
From edwin@integow.integrity.nl (Edwin Koedam)
Subject: Re: Help ! - Converting Proper case to Upper case in Vi.
Date: 4 Jun 93 06:54:19 GMT
Prasad Khurd writes:
> Hi there
>
> i read of a way to convert ALL upper case letters to lower case in the
> file in VI in one shot (not using ~ which works per charater) on the
> net somewhere but forgot it. i shall be very grateful if someone mails
> me how to do that.
Sorry, in my previous response, I converted all characters to uppercase.
To convert them to lower case, use:
:%s/./\l&/g
Edwin.
--
UUCP: ..!uunet!mcsun!sun4nl!integow!edwin or INTERNET: edwin@integrity.nl
Edwin Koedam, s

39
docs/casesr Normal file
View File

@ -0,0 +1,39 @@
From hansm@wsinti05.info.win.tue.nl (Hans Mulder)
From: hansm@wsinti05.info.win.tue.nl (Hans Mulder)
Newsgroups: comp.editors
Subject: Re: Changing case during search and replace in VI
Date: 14 Dec 1993 21:13:31 +0100
Organization: Eindhoven University of Technology, The Netherlands
Lines: 30
In <2eh2q5$67i@ionews.io.org> chowwi@ionews.io.org (Wing-Chi Chow) writes:
>Someone posted this awhile back, but I forgot to save the
>article :-(, so does anyone know how I can change
>the case of characters in a search and replace under VI.
>I think there were some commands like &U and &L.
In the replacement string:
\l changes the case of the next letter to lower case
\u changes the case of the next letter to lower case
\L changes case to lower case until \e or \E or end of replacement
\U changes case to upper case until \e or \E or end of replacement
& denotes the string that matched the search pattern
~ denotes the previous replacement string
\1 denotes the string that matched the part of the search string
between the leftmost \( and the corresponding \)
\2 ditto for second \(
\3 ditto for third \(
: : :
: : :
Thus :s/pattern/\U&/g changes all occurrences of "pattern" to upper case,
--
Hope this helps,
HansM

BIN
docs/chars.Z Normal file
View File

Binary file not shown.

BIN
docs/chars.tex.Z Normal file
View File

Binary file not shown.

BIN
docs/ckv.Z Normal file
View File

Binary file not shown.

BIN
docs/ckv2.Z Normal file
View File

Binary file not shown.

BIN
docs/course.Z Normal file
View File

Binary file not shown.

BIN
docs/course.tar.Z Normal file
View File

Binary file not shown.

BIN
docs/crypt.Z Normal file
View File

Binary file not shown.

BIN
docs/ctags.Z Normal file
View File

Binary file not shown.

BIN
docs/e2.tar.Z Normal file
View File

Binary file not shown.

BIN
docs/editech.1.Z Normal file
View File

Binary file not shown.

BIN
docs/editech.2.Z Normal file
View File

Binary file not shown.

BIN
docs/editech.3.Z Normal file
View File

Binary file not shown.

BIN
docs/editech.4.Z Normal file
View File

Binary file not shown.

BIN
docs/editech.5.Z Normal file
View File

Binary file not shown.

BIN
docs/editech.books.Z Normal file
View File

Binary file not shown.

BIN
docs/elvis.Z Normal file
View File

Binary file not shown.

BIN
docs/ex.changes.Z Normal file
View File

Binary file not shown.

BIN
docs/ex.fix.Z Normal file
View File

Binary file not shown.

BIN
docs/ex.reference.Z Normal file
View File

Binary file not shown.

Some files were not shown because too many files have changed in this diff Show More