commit - /dev/null
commit + 8d6e68fc21a02c9a133f2dbfe760939bf49729bf
blob - /dev/null
blob + b2c3b4d648e988989bcac59b8967322b736c36bf (mode 644)
--- /dev/null
+++ HELP
+
+ 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.
+
blob - /dev/null
blob + e3c0f08901bbe15c156113423ef0258777dd1c44 (mode 644)
--- /dev/null
+++ INDEX
+#
+# 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).
blob - /dev/null
blob + 520c5a1dc2eb25d8da47456e4bdf8f860a77fff9 (mode 644)
--- /dev/null
+++ README
+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/).
blob - /dev/null
blob + 32bb94c28e672d8b76a2c6b53758c9346095f38f (mode 644)
--- /dev/null
+++ WHO
+
+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...
+
blob - /dev/null
blob + 33470fda4dbd27a06c2348239abe1b3354c6819d (mode 644)
--- /dev/null
+++ comp.editors/8bit
+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 NgSTrm as ngstrm.
+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 `Mae', 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.
+
+
blob - /dev/null
blob + 9abeac107a163143f767d24957769b806440985e (mode 644)
--- /dev/null
+++ comp.editors/append
+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
\ No newline at end of file
blob - /dev/null
blob + 7a33aee29d11510185d38236a13760071760cc18 (mode 644)
--- /dev/null
+++ comp.editors/blankline
+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
+
blob - /dev/null
blob + bab6c8181d29e0bbc62de35c3384931da5a36f9e (mode 644)
--- /dev/null
+++ comp.editors/blockdel
+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
+
blob - /dev/null
blob + cd0f310bfaac021790ae00fffb9610daaff2bc3b (mode 644)
--- /dev/null
+++ comp.editors/blocks
+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
blob - /dev/null
blob + 1495f19d4c05d66f1c25f0e383174d6e0d173a07 (mode 644)
--- /dev/null
+++ comp.editors/buffer
+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
\ No newline at end of file
blob - /dev/null
blob + 7483e6d32026b5cc428c73c3f503e9ce7bb36c00 (mode 644)
--- /dev/null
+++ comp.editors/buffera
+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!
+
blob - /dev/null
blob + cd849d111520f8fa751525891828367d3a0f3c37 (mode 644)
--- /dev/null
+++ comp.editors/ced.tips.1
+From dberg@informix.com (David I. Berg)
+Newsgroups: comp.editors
+Subject: Re: In vi: How to delete from str1 to str2 ?
+Date: 6 Oct 91 20:42:49 GMT
+Status: O
+
+In article <1991Oct6.073919.9071@acsu.buffalo.edu> xiaofei@acsu.buffalo.edu (XiaoFei Wang) writes:
+>Suppose I have
+>
+>blabla string1 more blabla string2
+> ^^^^^^^^^^^^^^^^^^^^^^^^^^^
+>
+>and Now I wnat to delete all the underlined ( from string1 to string2 )
+>or replace it by something else, how do I do it in vi ?
+
+You can delete/change/yank from the cursor position up to but not
+including a character string. If, for instance, the character string
+following string2 was " string3", you would position your cursor on the
+first character you wish to delete/change/yank and enter 'd/ string3<cr>'
+to delete the underscored string in your example. (You would use 'y' to
+yank, and 'c' to change the string.) You can do this across several lines,
+eg. position your cursor on "instance" above and 'd/ example<cr>'. In the
+special case where you wish to delete/change/yank through the end of the
+line, just plain 'D' will delete and 'C' will change through the end of
+the line. If you wish to yank throuh the end of the line, you must 'y$'.
+
+ ___ ___ Consultant, Client Srvcs Engineering
+ / ) __ . __/ /_ ) _ __ Informix Software Inc. (303) 850-0210
+_/__/ (_(_ (/ / (_(_ _/__> (-' -/~ (_- 5299 DTC Blvd #740 Englewood CO 80111
+{uunet|pyramid}!infmx!dberg The opinions expressed herein are mine alone.
+
+
+From hrjoist@immd4.informatik.uni-erlangen.de (Holger Joist)
+Newsgroups: comp.editors
+Subject: Re: In vi: How to delete from str1 to str2 ?
+Date: 7 Oct 91 12:26:40 GMT
+Status: O
+
+xiaofei@acsu.buffalo.edu (XiaoFei Wang) writes:
+
+>Suppose I have
+
+>blabla string1 more blabla string2
+> ^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+>and Now I wnat to delete all the underlined ( from string1 to string2 )
+>or replace it by something else, how do I do it in vi ?
+
+How about:
+:s/string1.*string2/somethingelse/
+
+where somethingelse can be an empty string.
+
+Holger
+---
+Name : Holger Joist
+E-Mail: hrjoist@medusa.informatik.uni-erlangen.de
+
+
+From soh@andromeda.trl.OZ.AU (Kam Hung Soh)
+Newsgroups: comp.editors
+Subject: Re: In vi: How to delete from str1 to str2 ?
+Date: 7 Oct 91 22:12:04 GMT
+Status: O
+
+>Suppose I have
+
+>blabla string1 more blabla string2
+> ^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+>and Now I wnat to delete all the underlined ( from string1 to string2 )
+>or replace it by something else, how do I do it in vi ?
+
+You can try: 4cE
+ ^^
+ ||
+ |+--- End of space-delimited word
+ +---- Change
+
+``E'' can be substituted with ``W'' in this case.
+
+If you have the following line instead (C and C++ programming for
+accessing a member of a structure or record):
+
+blabla string1.more.blabla.string2
+
+You will have to type: ``7cw'' or ``7ce'' or ``cW'' or ``cE''. The
+lowercase range is used when words are not space delimited. You can
+also type ``C'' (in the same vein as ``D'' for delete until end of
+line) when you have to change all words until the end of the line.
+
+Regards,
+
+---
+Soh, Kam Hung email: h.soh@trl.oz.au tel: +61 3 541 6836
+Telecom Research Laboratories, POB 249 Clayton, Victoria 3168, Australia
+
+
+From dylan@ibmpcug.co.uk (Matthew Farwell)
+Newsgroups: comp.editors
+Subject: Re: In vi: How to delete from str1 to str2 ?
+Date: 7 Oct 91 08:21:53 GMT
+Reply-To: dylan@ibmpcug.co.uk (Matthew Farwell)
+Status: O
+
+In article <1991Oct6.073919.9071@acsu.buffalo.edu> xiaofei@acsu.buffalo.edu (XiaoFei Wang) writes:
+>Suppose I have
+>blabla string1 more blabla string2
+> ^^^^^^^^^^^^^^^^^^^^^^^^^^^
+>and Now I wnat to delete all the underlined ( from string1 to string2 )
+>or replace it by something else, how do I do it in vi ?
+
+:s/string1.*string2/wobble wobble im a gertrude/
+
+Dylan.
+--
+dylan@ibmpcug.co.uk || ...!uunet!uknet!ibmpcug!dylan
+Just follow the simple rule - Rob Pike
+
+
+From bill@camco.Celestial.COM (Bill Campbell)
+Newsgroups: comp.editors
+Subject: Re: In vi: How do I put line numbers in frant of each line ?
+Date: 8 Oct 91 04:04:53 GMT
+Status: O
+
+1:In <1991Oct6.214237.2266@acsu.buffalo.edu> xiaofei@acsu.buffalo.edu (XiaoFei Wang) writes:
+2:>Suppose I have
+3:>bla
+4:>blabla
+5:>blablabla
+6:>......
+7:>I would like to change it to
+8:>1 bla
+9:>2 blabla
+10:>3 blablabla
+11:>......
+12:>Is there a way to do this automatically in vi ?
+13:One way to do this within vi would be to put the cursor at the
+14:beginning of the first line and press !Ggrep -n '^.*$' As I did
+15:here (except that I put it at the beginning of the body of the
+16:message). This gives line number separated by ':'
+17:
+18: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
+
+
+From roger@quantime.co.uk (Roger Phillips)
+Newsgroups: comp.editors
+Subject: Re: writing from buffers
+Date: 11 Oct 91 16:02:41 GMT
+Status: O
+
+In article <1991Oct10.081809.16080@apricot.co.uk>,
+peters@apricot.co.uk (Peter Smith) writes:
+> Is is possible in vi to write from named buffers?
+> This seems a perfectly acceptable thing to do,
+> but attempts using ":'aw filename" do not appear to work.
+ ^^
+The single quote means "the line marked 'a'".
+In vi, you refer to named buffers using "a (for example).
+But in ex (the mode you're in for a command starting with ':'),
+the " is a comment symbol, so
+:"aw filename
+is simply a comment, with no effect.
+Named buffers are purely a vi-mode thing, I think,
+so, no, you can't refer to them in any ex-mode commands
+(such as :w).
+
+However, since you have what you want in a named buffer,
+you can use
+:e filename<RETURN>"ap
+that is, edit the new file and 'put' the buffer contents.
+
+--
+Roger Phillips roger@quantime.co.uk
+
+
+From mitchell@mdd.comm.mot.com (Bill Mitchell)
+Newsgroups: comp.editors
+Subject: Re: How to disable 'vi' beep?
+Keywords: beep bell dope vi
+Date: 21 Oct 91 15:43:01 GMT
+Status: O
+
+In article <1665@baby.and.nl> jos@and.nl (Jos Horsmeier) writes:
+>In article <1991Oct18.172458.17044@ux1.cso.uiuc.edu> d-lewart@uiuc.edu (Daniel S. Lewart) writes:
+>|There is a novice 'vi' user in my office. Every two seconds a beep emanates
+>|from his terminal. How can this beep be disabled? Typing 'set noerrorbells'
+>|does not disable the beep one gets from pressing the 'Escape' key ten times.
+>
+>I would have loved to know the answer to that! Years ago I worked at a
+>university with lots of newbies. All these beeps worked like a chinese
+>water torture! We ended up, cutting all the wires from the speakers ...
+>We couldn't stand it no more 8^)
+>
+>Jos aka jos@and.nl
+
+You might try having novice users invoke vi thru a shell script like
+the following:
+
+ vi x | tr -d '\007'
+--
+mitchell@mdd.comm.mot.com (Bill Mitchell)
+
+
+From mitchell@mdd.comm.mot.com (Bill Mitchell)
+Newsgroups: comp.editors
+Subject: Re: How to disable 'vi' beep?
+Keywords: beep bell dope vi
+Date: 21 Oct 91 16:11:32 GMT
+Status: O
+
+In article <1991Oct21.154301.12900@mdd.comm.mot.com> mitchell@mdd.comm.mot.com (Bill Mitchell) writes:
+>
+>You might try having novice users invoke vi thru a shell script like
+>the following:
+>
+> vi x | tr -d '\007'
+
+Let me be the first to take myself to task for posting this in haste.
+
+1. This worked at a quick trial from the command line, and I posted.
+
+2. After seeing it appear (oops), I tried it as a script with "$1"
+ instead of "x". Suprise - it didn't work. BELs got through.
+ Seems my shell issues BELs at multiple escapes, and tr isn't placed to
+ filter these BELs off.
+
+3. This approach might have problems anyway (and might not) depending
+ on what type of terminal the user is using. On some terminals, the
+ '\007' might show up other than as a BEL character - as part of a
+ cursor positioning sequence for example.
+
+Anyway, it might be worth trying
+
+ vi filename | tr -d '\007'
+
+from the command line. If that works, maybe it'll work as an alias.
+
+--
+mitchell@mdd.comm.mot.com (Bill Mitchell)
+
+
+From ruhtra@turing.toronto.edu (Arthur Tateishi)
+Newsgroups: comp.editors
+Subject: Re: Tabs as spaces in VI.
+Date: 22 Oct 91 04:25:58 GMT
+Status: O
+
+In article <1991Oct21.221438.223@acsu.buffalo.edu> xiaofei@acsu.buffalo.edu (XiaoFei Wang) writes:
+>/* From the keyboard of eric@tfs.com (Eric Smith) */:
+>* I'm not sure what the original poster wanted, but can someone tell me
+>* how to disable vi's usage of tab as a fill character? i.e., when it
+>* does autoindent, it uses a mixture of tabs and spaces. I just want it
+>* to use spaces.
+>
+>In my opinion, TABs are just a group of spaces and I prefer spaces and
+>use TABs as less as possible.
+>
+>To answer your question as how to disable vi's usage TAB as filling
+>character, you need to
+>
+>set tabstop=1
+>
+>This will set TAB = a single space. I have tested and it worked.
+
+Not quite. It looks right in vi but what you have really done is
+cause lots and lots of tabs to be inserted into the document in
+order to get indenting. Instead, use:
+set tabstop=200
+So that vi thinks it can't use tabs to get the required small amount
+of indent. Of course, this now becomes dangerous when you actually
+hit tab or load in files with tabs already present. Therefore,
+you may also consider mapping tab in insert mode to ^D which does
+the desired thing a lot of the time.
+map! ^V^I ^D
+
+--
+"The first fact to face is that UNIX was not developed with security, in any
+reliable sense, in mind; this fact alone guarantees a vast number of holes."
+ -- "On the Security of UNIX", Dennis M. Ritchie
+Arthur Tateishi ruhtra@turing.utoronto.ca
+
+
+From krisk@ux1.cso.uiuc.edu (Kris Klindworth)
+Newsgroups: comp.editors
+Subject: Re: vi question, replace second occurence
+Keywords: vi, s-e
+Date: 24 Oct 91 16:24:54 GMT
+Status: O
+
+hess@rosun1.informatik.uni-hamburg.de (Hauke Hess) writes:
+
+>Hi,
+
+>I'm working on a TeXnification of the jargon file. That's not too difficult,
+>but there is one thing I would like to do by Search&Replace, which I don't
+>know how:
+
+>In the Jargonfile are many words enclosed in ", like the following sentence
+
+>the "slow" brown fox jumps over the "crazy" dog.
+
+>I want to change that sentence in:
+
+>the ``slow'' brown fox jumps over the ``crazy'' dog.
+
+>for the sake of typographical correctness. In other words: how do I replace
+>each second occurence of a string with another, with not respect to lineends
+>between the words?
+>So a sentence like
+
+>there is a "problem
+>extraordinaire" in here.
+
+>should be replaced as well.
+
+>I thought it would have somthing to do with "finding the Nth occurrence"
+>as asked a few letters ago, but the answers on that weren't that helpfull.
+
+
+For this problem you can use
+:%s/"\</``/
+and
+:%s/\>"/''/
+
+The special pattern \< matches the beginning of what vi considers a word
+and \> matches the end. You'll still have to check the file to resolve
+the cases that vi didn't consider words, but this should handle the
+bulk of your changes.
+
+
+------------------------------------------------------------------------------
+Kris Klindworth Internet: krisk@ux1.cso.uiuc.edu
+Database Programmer/Analyst Phone : (217)244-7120
+Illinois State Water Survey US Mail : 2204 Griffith Dr
+ Champaign, IL 61820
+
+
+From gwc@root.co.uk (Geoff Clare)
+Newsgroups: comp.editors
+Subject: Re: vi question - am I so different?
+Date: 24 Oct 91 18:07:31 GMT
+Status: O
+
+In <28900002@teecs.UUCP> belkin@teecs.UUCP (Hershel Belkin) writes:
+
+>Thanks for the attempted answers, but no cigar yet!!
+>Any other suggestions, or should I start looking for
+>a _real_ editor?
+
+Here's a macro that provides repeated "n" commands.
+
+ :map ^N In^V^[l"zd^@z
+
+where ^V, ^N and ^[ are CTRL-V, CTRL-N and ESC (but ^@ is ^ then @).
+
+To use it, search for the first occurrence of the string, then type
+
+ <number> CTRL-N
+
+E.g. to search for the 96th occurrence of the string "xyz", type:
+
+ /xyz^M96^N
+
+The reason this has a 96 instead of a 95 is that the macro actually
+searches from the beginning of the current line, not from the cursor, so
+it finds the first match again (unless it's at the beginning of the line!)
+You just have to be a bit careful when there are multiple matches on a
+line, otherwise it works OK.
+
+If anyone can think of a way round the "beginning of line" problem, I'd
+like to hear it!
+--
+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 krisk@ux1.cso.uiuc.edu (Kris Klindworth)
+Newsgroups: comp.editors
+Subject: Re: vi question - am I so different?
+Date: 24 Oct 91 22:48:08 GMT
+Status: O
+
+gwc@root.co.uk (Geoff Clare) writes:
+
+>In <28900002@teecs.UUCP> belkin@teecs.UUCP (Hershel Belkin) writes:
+
+>>Thanks for the attempted answers, but no cigar yet!!
+>>Any other suggestions, or should I start looking for
+>>a _real_ editor?
+
+>Here's a macro that provides repeated "n" commands.
+
+> :map ^N In^V^[l"zd^@z
+
+>where ^V, ^N and ^[ are CTRL-V, CTRL-N and ESC (but ^@ is ^ then @).
+
+>If anyone can think of a way round the "beginning of line" problem, I'd
+>like to hear it!
+
+Cool solution. Much better than the one I was about to post. I
+got around the beginning of line problem by marking the beginning position
+first and then returning to it before running the @z.
+Your macro would be something like this
+
+ :map ^N mzIn^V^[l"zd^`z@z
+
+------------------------------------------------------------------------------
+Kris Klindworth Internet: krisk@ux1.cso.uiuc.edu
+Database Programmer/Analyst Phone : (217)244-7120
+Illinois State Water Survey US Mail : 2204 Griffith Dr
+ Champaign, IL 61820
+
+
+From malte@techfak.uni-bielefeld.de (Malte Uhl)
+Newsgroups: comp.editors
+Subject: Re: vi question - am I so different?
+Date: 25 Oct 91 10:17:39 GMT
+Status: O
+
+In article <3553@root44.co.uk>, gwc@root.co.uk (Geoff Clare) writes:
+|>
+|> Here's a macro that provides repeated "n" commands.
+|>
+|> :map ^N In^V^[l"zd^@z
+|>
+|> where ^V, ^N and ^[ are CTRL-V, CTRL-N and ESC (but ^@ is ^ then @).
+|>
+|> To use it, search for the first occurrence of the string, then type
+|>
+|> <number> CTRL-N
+|>
+|> E.g. to search for the 96th occurrence of the string "xyz", type:
+|>
+|> /xyz^M96^N
+|>
+|> The reason this has a 96 instead of a 95 is that the macro actually
+|> searches from the beginning of the current line, not from the cursor, so
+|> it finds the first match again (unless it's at the beginning of the line!)
+|> You just have to be a bit careful when there are multiple matches on a
+|> line, otherwise it works OK.
+|>
+|> If anyone can think of a way round the "beginning of line" problem, I'd
+|> like to hear it!
+
+Here it is:
+ :map ^N In^V^[l"zd^n@z
+
+just add another n to it.
+
+One could also do some experiments with ``, which means "go back to the letter
+you were before the last command". I'm not familiar with this command; I
+usually use '', which goes back to the line before the last command.
+
+
+Article: 3325 of comp.editors
+From lshaw@ccwf.cc.utexas.edu (Logan Shaw)
+Subject: Re: vi question, replace second occurence
+Keywords: vi, s-e
+Date: 26 Oct 91 01:08:15 GMT
+
+hess@rosun1.informatik.uni-hamburg.de (Hauke Hess)
+
+wants to change
+
+ the "slow" brown fox jumps over the "crazy" dog.
+
+to
+
+ the ``slow'' brown fox jumps over the ``crazy'' dog.
+
+>So a sentence like
+>
+>there is a "problem
+>extraordinaire" in here.
+>
+>should be replaced as well.
+
+His approach to the problem was to replace every _other_ occurence
+of the double quote character ('"').
+
+I'd like to suggest a different approach. Replace the quote characters
+one of the two replacement strings, determining which to replace
+them with by the surrounding characters.
+
+If the quote is at the beginning of the line, it should be a beginning
+quote. If at the end of the line, and end quote. This assumes
+you're not going to have a sentence like this:
+
+ His name was "Phroed
+ " and he was green.
+
+nor like this:
+
+ I'm watching the TV program "
+ Matlock."
+
+If a quote has a alphanumeric character before it, and not after it,
+it should be replaced with and ending quote, and vice versa. If it
+has a space before it and not after it, an ending quote, and vice versa.
+
+The regexp's for this would be something like:
+
+:%s/^"/``/
+:%s/"$/''/
+:%s/ "\([^ ]\)/ ``\1/g
+:%s/\([^ ]\)" /\1'' /g
+:%s/\([a-z0-9]\)"\([^a-z0-9]\)/\1''\2/g
+:%s/\([^a-z0-9]\)"\([a-z0-9]\)/\1``\2/g
+
+Hope this helps...
+
+Adios,
+ Logan
+--
+: Our trial is which car to buy. Temptation is that extra dessert. :
+|In the land of orange juice you're better off with the right kind of shirt.|
+| But take away the naivete; expose the sources of our fears. |
+:We'll run to missiles if we're pushed too far- proceed to blow it all away.:
+
+
+From gast@oahu.cs.ucla.edu (David Gast)
+Newsgroups: comp.editors
+Subject: Re: vi question, replace second occurence
+Keywords: vi, s-e
+Date: 28 Oct 91 00:13:51 GMT
+Status: O
+
+In article <hess.688300281@rosun1> hess@rosun1.informatik.uni-hamburg.de (Hauke Hess) writes:
+
+> how do I replace each second occurence of a string with another [ignoring]
+> lineends.
+
+>there is a "problem
+>extraordinaire" in here.
+
+>should be replaced as well.
+
+First off, I am not sure that 100% automated process will work correctly.
+There is a chance that a problem will develop. For example, there could
+be a " missing, or an extra one inserted in the wrong place. Additionally,
+at some point, " could be used by itself as in this sentence.
+
+I would first check for some of the above and I would see if you have any
+"' or '" pairs. Assuming that everything is as it should be, then I suggest
+the following. It is not the fastest way possible, but you can look at
+the screen and make sure that everything appears to be working properly.
+
+1. /" (that is, search for a ")
+2. put the cursor before the current position in file)
+
+3. Define the following maps. You can use any lefthand side character that
+ you want.
+
+ :map b ns``^V^M
+ :map e ns''^V^M
+ :map g bebebebebebebebebebebebebebebebebebebebebebebebebebebebebebebebebe
+
+4. Now type g as many times as necessary. You could do something like
+
+ :map G ggggggggggggggggggggggggggggggggggggggggggggg
+
+ and then type G as many times as necessary.
+
+If you save your file frequently, then when something goes wrong, you have
+the problem isolated to a relatively small area. Perhaps I am being
+pessimistic, but I suspect there is at least one typo in a file that
+has over one meg in it.
+
+David
+
+
+From hansm@cs.kun.nl (Hans Mulder)
+Newsgroups: comp.editors
+Subject: Re: removing first field from a number of lines with vi
+Date: 29 Oct 91 17:52:28 GMT
+Status: O
+
+In <5561@julian.uwo.ca> creider@taptet.sscl.uwo.ca (Chet A. Creider) writes:
+>I know this is easily done with awk, but would like to know if it
+>can be done with vi--if one has a file with data in tab-separated
+>fields and wants to remove the first field from each line (in other
+>words a dw done at the beginning of each line in the file), how
+>can this be done?
+
+Those are two different questions.
+
+If you want to delete everything up to and including the first tab,
+you could do
+
+:%s/[^ ]* //
+ ^ ^ those are tab characters
+
+If, on the other hand, you want the equivalent of a dw at the beginning of
+each line, you would say:
+
+:%s/[a-zA-Z0-9_]*[ ]*//
+ ^tab ^space
+
+You can leave off trailing slashes on a :s command if you hate wearing out
+your '/' key. (Or you can use another punctuation character ;-)
+
+I don't see any obvious way to get either of these effects by filtering
+the buffer through awk. But if you know an awk command that does what you
+want, you can say from within vi
+
+1G!G awk 'whatever'
+
+and it ought to work.
+
+--
+Hope this helps,
+
+Hans Mulder hansm@cs.kun.nl
+
+From s887212@minyos.xx.rmit.oz.au (S.Riehm)
+Newsgroups: comp.editors
+Subject: Re: Smart 'C' editors?!?
+Date: 29 Oct 91 22:36:49 GMT
+Status: O
+
+valley@gsbsun.uchicago.edu (Doug Dougherty) writes:
+
+>A couple of (presumably dumb) questions:
+> 1) What does map! do (as opposed to plain ol' map) ?
+> 2) What do things like /*, ca', and ei' mean as map! targets?
+> (They sure don't look like keys to me)
+
+1: map! defines mappings for keys while in insert mode
+2: you can map strings, vi will give you time to type the whole
+string, and that string will b instantly replaced by whatever you have
+mapped it to. if you set notimeout, vi will wait forever when you
+start typing a map string, which can be most annoying if you actually
+want the string. this is also why J-P Radly put the ' on the end of
+his macros, because you rarely type wh'.
+When timeout is set vi will wait about one second after each character
+in a macro string before timing out and simply using the string as
+typed
+
+ALSO...
+>jpr@jpradley.jpr.com (Jean-Pierre Radley) writes:
+
+>>And these macros might be of interest to you:
+
+>>se nu ts=5 wm=0 sw=5
+>>map! /* /* */hhi
+>>map! ca' case : break;k0f:i
+>>map! ei' else if () {}kk0f(a
+>>map! el' else {}ki
+>>map! if' if () {}k0f(a
+>>map! fo' for (;;) {}k0f(a
+>>map! wh' while () {}k0f(a
+>>map #0 :!cc %
+
+firstly: there is no reason to set ts=5, tabs are 8 characters by
+default on 99% of the machines that I have ever heard of, if you less
+or more your code you will get a nasty surprise. Instead, get used to
+using ^T and ^D to do your indenting and outdenting (!?) instead of
+tabs. vi will put tabs in for you where appropriate!
+
+secondly: I played with macros like these some time ago, but found
+them somewhat clumsy, I have now come up with a system of bracketing
+and jump points. by mapping an unused key to be my 'jump to next jump
+point' I can quickly nest any number of brackets, and jump around
+within them with a minimum of fuss. Here the we use backspace (^H)
+in-stead of del keys, so the del key is my jump key.
+
+I have defined a jump point as two tilde's ( ~~ ) as I have NEVER seen
+this string in any code or text thus far :-)
+
+--- cut here ---
+:set magic sw=4 ai
+" jump to next jump point
+:map ^? /\~\~^M2s
+:map! ^? ^[/\~\~^M2s
+:map! (( ( )~~^[3hi
+:map! () ()~~^[2hi
+:map! [[ [ ]~~^[3hi
+:map! [] []~~^[2hi
+:map! "" ""~~^[2hi
+:map! '' ''~~^[2hi
+" new block definition
+:map! }{ ^[A^M{^M}~~^[O^T
+:map! {{ { }~~^[3hi
+:map! {} {}~~^[2hi
+:map! (_ ( );~~^[4hi
+:map! (+ ( ~~ )}{~~^[?\~\~.*)^M2s
+:map! // /* ^I*/^[F a
+:map! *& /*^M */~~^[O*
+:map! *_ /*^M^M*/^[2ko^M
+:map! /- ^[0i/*-^[x76po^M^M*/~~^[kO^I
+" #include lines made easy
+:map! >< .h>^[Bi<`in^[A
+:map! >" .h"^[Bi"`in^[A
+" other # lines made easy
+:map! `if ^[0i#ifdef
+:map! `el ^[0i#else
+:map! `li ^[0i#elseif
+:map! `en ^[0i#endif
+:map! `in ^[0i#include
+:map! `de ^[0i#define
+:map! argcv argc, argv^[oint argc;^Mchar **argv;^[/\~\~^M2s
+--- cut here ---
+
+I will leave you to work out which ^'s are ^V's :-)
+
+one of the problems with these macros is that they tend to make
+cutting and pasting in Xwindows a little nasty at times, I know of one
+person who has put a ^U in front of the (( type macros to prevent
+this.
+
+hope these help your productivity
+
+catchya
+
+======================================================================
+Stephen Riehm [Romulis] s887212@minyos.xx.rmit.edu.au
+BKX Australia Phone: +61 3 889 0459 Fax: +61 3 889 3227
+== Disclaimer: I claim no responsibility for my employer's actions. ==
+
+
+From krisk@ux1.cso.uiuc.edu (Kris Klindworth)
+Newsgroups: comp.editors
+Subject: Re: vi question, replace second occurence
+Keywords: vi
+Date: 30 Oct 91 19:00:29 GMT
+Status: O
+
+(Johathan Chin ask me to post this followup for him. Evidently
+ they are having problems with their news system. krisk@ux1.cso.uiuc.edu)
+
+In article <1991Oct24.162454.4759@ux1.cso.uiuc.edu> krisk@ux1.cso.uiuc.edu (Kris Klindworth) writes:
+>hess@rosun1.informatik.uni-hamburg.de (Hauke Hess) writes:
+>
+>>In the Jargonfile are many words enclosed in ", like the following sentence
+>
+>>the "slow" brown fox jumps over the "crazy" dog.
+>
+>>I want to change that sentence in:
+>
+>>the ``slow'' brown fox jumps over the ``crazy'' dog.
+>
+>>for the sake of typographical correctness. In other words: how do I replace
+>>each second occurence of a string with another, with not respect to lineends
+>>between the words?
+>>So a sentence like
+>
+>>there is a "problem
+>>extraordinaire" in here.
+>
+>>should be replaced as well.
+>
+>For this problem you can use
+>:%s/"\</``/
+>and
+>:%s/\>"/''/
+
+Perhaps a better way is:
+:g/$/s/"\([^"]*\)"/``\1''/g
+
+which replaces all occurrences of "string" in the file. It does not
+touch strings that extend over line boundaries though. For that, you
+could look for the last " on a line, change it to ``, go to next
+occurrence of " and change to ''. Something like (untested):
+
+:1|s/"\([^"]*\)$/``\1/|s/^\([^"]*\)"/\1''/
+
+which changes the first occurrence of the quoted string. Perhaps wrapping
+this in a global will work:
+
+:g/$/1|s/"\([^"]*\)$/``\1/|s/^\([^"]*\)"/\1''/
+
+but I haven't tried it.
+
+Have fun,
+
+Jonathan Chin
+shrchin@uk.ac.rdg.susssys1
+Department of Cybernetics, University of Reading, England.
+
+From asylvain@felix.UUCP (Alvin "the Chipmunk" Sylvain)
+Newsgroups: comp.editors
+Subject: Re: filling paragraph in vi
+Date: 30 Oct 91 21:17:12 GMT
+Status: O
+
+Written in article <754@skyking.UUCP>
+ by jc@skyking.UUCP (J.C. Webber III):
+
+: In <CKCLARK.91Oct18135300@paris.mit.edu> ckclark@athena.mit.edu
+: (Calvin Clark) writes:
+:
+: >Novice question:
+:
+: >How does one fill a paragraph in vi?
+:
+: It requires an external unix command (ie. fmt or mfold).
+: Many unix systems have a formating command called fmt. To use it
+: within vi you would position your curser on the first character of
+: the paragraph that you would like to format and then type "!}fmt"
+: (without the qoutes). If you desire more or less characters than
+: the default (72 I think), say 60, then you would type "!}fmt 60".
+
+Yours may work that way. Mine attempts to format a file named "60".
+
+Ah, here we go ... "!}fmt -60" seems to work. Never thot of that.
+Always wanted that feature, and could never get it to work. Oh well.
+
+: For those systems that do not have fmt, there is a public domain
+: program called mfold that does the job quite nicely. The only problem
+: I have with it (and I have to use it because I don't have fmt) is that
+: it drops one of the double spaces after the period between sentences.
+: I have to go back and put them back in by hand. If anyone has a fix
+: for this inconvience I would appreciate it.
+
+I have a "fix," but it's rather long. However, it has the additional
+features of automatically hyphenating long multi-syllabled words that
+almost fit, plus you can turn that off on demand, or, change the line
+length, indentation, etc., on demand.
+
+This makes two important assumptions, and they are:
+ 1) You have "nroff" on your system, located in /usr/bin
+ This is the powerhouse, the engine that drives the utility. This is
+ what allows you to do damn near any kind of ASCII text formatting
+ you'd want.
+ 2) You have "lex" on your system.
+ This gives you the auto-double-spaces after sentences. "nroff"
+ doesn't do that, relying on the user to add these where needed.
+ I guess that saves it from figuring out "Mr." etc. Well, all
+ that's loaded into the "lex" source code provided below.
+
+If you do NOT have "lex", this can still work if you write a "pre_nroff"
+utility by hand. It's job in life is to guarantee that periods at the
+end of sentences have two spaces, something that "nroff" leaves to the
+user. Have it filter stdin to stdout.
+
+Of course, if you don't have "lex", you probably don't have "nroff" either.
+
+First, you copy this shell script and put it on your path somewhere. Call
+it "Nroff". It's contents are as follows:
+
+--------cut here--------Begin of Nroff--------
+#!/bin/csh -f # start quicker by avoiding .cshrc
+#
+# Nroff:
+# This script allows me to use "nroff" to format paragraphs from "vi"
+# Written for the C-shell.
+#
+# Alvin "the Chipmunk" Sylvain
+
+if ( $#argv == 0 ) then # no arguments, use the default
+ pre_nroff | /usr/bin/nroff -i ~/.Nroff.default
+else # construct a new defaults file from arguments
+ cp ~/.Nroff.default ~/.Nroff.temp
+
+ while ( $#argv > 0 ) # add new parms to specifications
+ switch ( $1 ) # check for no-arg parms.
+ case .nh: # no hyphenate
+ case .nf: # no fill
+ case .fi: # fill
+ case .na: # no adjust (turn off right justification)
+ case .ad: # adjust (turn on right justification)
+ echo $1 >> ~/.Nroff.temp
+ shift # advance to next parameter(s)
+ breaksw
+ case *: # all else is assumed to be 1-arg parms
+ echo $1 $2 >> ~/.Nroff.temp
+ shift # advance to next parameter(s)
+ shift
+ breaksw
+ endsw
+ end
+
+ pre_nroff | /usr/bin/nroff -i ~/.Nroff.temp
+
+ /bin/rm -f ~/.Nroff.temp
+endif
+--------cut here--------End of Nroff--------
+
+Now, this uses a permanent datafile with defaults that instruct "nroff"
+on how to format a paragraph. They are stored in "$HOME/.Nroff.default",
+and the ones I've selected that suit me are:
+
+--------cut here--------Begin of $HOME/.Nroff.default--------
+.na
+.pl 1
+.ll 72
+.hy 12
+--------cut here--------End of $HOME/.Nroff.default--------
+
+The "nroff" commands above are:
+ .na - no adjust (turns off right justification)
+ .pl 1 - page length of 1 (otherwise, it adds enough empty lines to
+ fill a page)
+ .ll 72 - line-length of 72 (obvious enough)
+ .hy 12 - shoot, I forget how this works, but it controls how it
+ hyphenates. RTFM.
+
+You can change these defaults, naturally, but I recommend you leave in
+the ".pl 1", otherwise, it will give you an entire page each time you
+use it to format a paragraph. That results in your paragraph followed
+by enough empty lines to make whatever the page size is.
+
+"pre_nroff" is a filter written in "lex" that makes certain, more or
+less, that the number of spaces after periods is correct. It repairs
+the complaint in J.C.Webber's article that prompted this whole thing.
+It also handles question marks, exclamation points, quotes, close
+parentheses, hyphens, and a few titles ("Mr.", "Dr.").
+
+It's contents are:
+
+--------cut here--------Begin of pre_nroff.lex--------
+punct [\.\!\?]
+tbsp [\t ]
+tbspnl [\t \n]
+clsprn [\"\)\]\}]
+%%
+"-"{tbspnl}+ ;
+etc\." " printf ("etc. ");
+Dr\.{tbspnl}+ printf ("Dr. ");
+Mr\.{tbspnl}+ printf ("Mr. ");
+Mrs\.{tbspnl}+ printf ("Mrs. ");
+{punct}{tbsp}+ printf ("%c ", yytext [0]);
+{punct}{clsprn}{tbsp}+ printf ("%c%c ", yytext [0], yytext [1]);
+{tbsp}+ printf (" ");
+--------cut here--------End of pre_nroff.lex--------
+
+My version appears to have a bug in handling an ellipis (...) so I left
+that line out of this version. As you can see, it also attempts to han-
+dle "Mr. Smith" correctly, but naturally will fail if "Mr." is the last
+word on the sentence. It also attempts to handles periods within
+quotes, so that, eg., "These are my words." will be treated as a sen-
+tence, with two spaces after the ending quote.
+
+The paragraph above was left exactly as processed by the pre_nroff/nroff
+combination, so you can see exactly where it works and where it fails.
+Apparently the period-quote combination overrides the "Mr." check, ie.,
+it puts two spaces after the period despite the title. Well, it ain't
+perfect, obviously, and it certainly can't read your mind.
+
+It handles hyphens by eliminating them ONLY from the ends of lines.
+Ie., if the hyphen ends the line, it is removed and the word beginning
+the next line is glued to the word ending the current line. Within the
+line, they are ignored. This has an advantage and a disadvantage.
+
+The advantage is that if you modify the text such that the word no
+longer needs to be hyphenated, "pre_nroff" will glue the pieces back
+together again. "nroff" doesn't do this, assuming that you are using
+separate source and target files. The disadvantage is that words that
+are SUPPOSED to be hyphened, such as "mother-in-law," that "nroff" hap-
+pened to break at the line-end, will ALSO be glued back together. If
+you use such words, you have to watch out for them.
+
+To create the program "pre_nroff" from this "lex" source, perform the
+following:
+
+ lex -t pre_nroff.lex > pre_nroff.c
+ cc -o pre_nroff pre_nroff.c -ll
+
+USAGE:
+
+Don't forget to "chmod +x Nroff" in whichever directory you've placed
+it. You may also have to enter the "rehash" command before trying it.
+
+To run it from inside "vi", follow essentially the same instructions as
+for "fmt", ie., place your cursor at the beginning of the paragraph you
+wish to format. The paragraph is delimited by empty lines. Enter:
+
+ !}Nroff
+
+and you'll get a more-or-less perfectly formatted paragraph, including
+hyphenation where needed.
+
+You may pass parameters to "Nroff" in the form of "nroff"
+dot-commands. For example, if you want a shorter line-
+length, as exemplified in this paragragh, specify the new
+line-length as follows:
+
+ !}Nroff .ll 60
+
+Any "nroff" command (that I can think of and have tested) can be used.
+The common ones with no arguments are handled, as you can see in the
+"Nroff" script above, and all others are assumed to have exactly one
+argument. You can not use any "nroff" dot-commands with more than one
+argument, altho in common "vi" use you shouldn't need any.
+
+For example, I have re-formatted one of my above paragraphs with right-
+justification, line-length 65, and indentation of 5.
+
+ My version appears to have a bug in handling an ellipis
+ (...) so I left that line out of this version. As you can
+ see, it also attempts to handle "Mr. Smith" correctly, but
+ naturally will fail if "Mr." is the last word on the sen-
+ tence. It also attempts to handle periods within quotes, so
+ that, eg., "These are my words." will be treated as a sen-
+ tence, with two spaces after the ending quote.
+
+That was performed with the command:
+
+ !}Nroff .ad .ll 65 .in 5
+
+Notice: If you make changes to an indented paragraph like the one above,
+remove the indentations before re-running the "Nroff" command. This can
+be done by placing the cursor at the beginning of the paragraph, then
+entering "<}" until the paragraph is lined up on the left margin again.
+Otherwise, your results will be somewhat peculiar. I'm not sure why.
+
+CONCLUSION:
+
+Now, with all the discussions going back and forth about "vi's" ability
+or inability to handle formatting, and the FAQ about using "fmt" or some
+clone, I have quietly put this little package together for my own use,
+and it seems to work fine. This is the first time it's been published.
+
+If you try it, I'd appreciate feedback. Murphy's law being what it is,
+I'm almost 100% sure I left SOMEthing out, but we'll see.
+
+--
+Alvin "the Chipmunk" Sylvain, alvin@stanton.cts.com, asylvain@felix.UUCP
+DISCLAIMER: It's all in fun, folks, no flames intended. IF you're real
+nice, I _might_ just let you have my opinion for free!
+OBLIGATORY QUOTE FOR THE DAY:
+You are afraid to eat your words. There is no need to be. I have eaten
+a great many of mine in my time and on the whole I have found them a
+most wholesome diet.
+ -- Winston Churchill
+
+
blob - /dev/null
blob + 9f42b305a48d3611bd7bee5eb3b3fb55fa4ce4c6 (mode 644)
--- /dev/null
+++ comp.editors/ced.tips.2
+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)
+
+
blob - /dev/null
blob + 8c16d06ac2de5ae02fa9cce569c476f479226148 (mode 644)
--- /dev/null
+++ comp.editors/ced.tips.3
+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
+
+
blob - /dev/null
blob + e6f6e4096b12d490c0a8c80d5d023819095468a3 (mode 644)
--- /dev/null
+++ comp.editors/ced.tips.4
+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
+
blob - /dev/null
blob + 6fa655f42e061df13abc7835a8e5f4466a508f34 (mode 644)
--- /dev/null
+++ comp.editors/ced.tips.5
+From buboo@alf.uib.no (Ove Ruben R Olsen)
+Subject: Re: Good names for vi macros
+Date: Wed, 5 Feb 92 11:08:28 GMT
+Status: O
+
+Jan Van den Bussche (vdbuss@bigeye.cs.indiana.edu) writes:
+>I hope this is not something which was already discussed at length here, or
+>worse, a FAQ.
+
+This was discussed last summer I belive... :-) AND it should be in a VI-faq.
+
+>
+>My question is: does anyone has suggestions concerning which names to choose
+>for naming macros? For example, it is probably not a good idea to remap the
+>"cursor" keys k,h,j,l (which are actually already macros themselves)
+>to other commands. More generally, i frequently have a hard time finding
+>a name for a certain macro, that is not yet "occupied".
+
+>From the UCB-docs on VI (vi.chars.Z in the VI/EX archives):
+
+^A Unused.
+^C Unused.
+^K Unused.
+^O Unused.
+^S Unused. Some teletype drivers use ^S to
+ suspend output until ^Q is.
+^X Unused.
+^\ Unused.
+^_ Unused. Reserved as the command character
+ for the Tektronix 4025 and 4027 terminal.
+* Unused.
+K Unused.
+V Unused.
+\ Unused.
+_ Unused.
+g Unused.
+q Unused.
+v Unused.
+~ Unused.
+
+---
+NOTE that ^S is not a too wise char to map, unless you are into heavy
+pain or wizzardry :-)
+
+Instead of maping one char at the time you can map two and three chars.
+This will expand your "map-space" a lot.
+I considder this The Right Way to do it, as all of VI's commands are valubale
+in general editing. In this way it is also simpler to find memonics for
+your macros.
+
+For instance, in one of my .exrc files i may have this two mappings:
+
+ :map #e :wq!^M
+ :map! #e ^[:wq!^M
+
+When in command mode I can hit #e and exit the editor. When in one of the
+textmodes, I can also hit #e and I'll exit the editor. I've used #e due to
+that #e is not a commom key-combination for me. Your milage may vary.
+
+OR:
+ :map #n :w!^M:n^M
+ :map! #n ^[:w!^M:n^M
+
+To get on to the next file in a multifile editing session.
+Keeping the same chars to both :map and :map! saves me from remebering to
+many macros.
+Instead of :map! one can also use abbrevations. This is perhaps a better way
+to do it, 'cuz one don't have to take care of the timelimit of :map!.
+
+As a general rule: One should not alter the command set, only expand it.
+
+>
+>Thanks in advance,
+>
+>--Jan Van den Bussche, vdbuss@cs.indiana.edu
+
+\Ruben.
+
+
+--
+ Ove Ruben R Olsen, Proffessional VI user. EMAIL: rubenro@viggo.blh.no
+ Also known as "The Gnarfer from Hell". (Registered character of ORRO.)
+ Maintaining the Largest VI/EX-STUFF Archive in the WORLD (alf.uib.no)
+ :wq!
+
+
+From steinbac@hpl-opus.hpl.hp.com (Guenter Steinbach)
+Subject: Re: Good names for vi macros
+Date: 7 Feb 92 20:20:48 GMT
+Status: O
+
+> / hpl-opus:comp.editors / buboo@alf.uib.no (Ove Ruben R Olsen) / 3:08 am Feb 5, 1992 /
+>
+> Instead of maping one char at the time you can map two and three chars.
+> This will expand your "map-space" a lot.
+> I considder this The Right Way to do it, as all of VI's commands are valubale
+> in general editing. In this way it is also simpler to find memonics for
+> your macros.
+
+Right. I use a lot of "*x"-style macro names. A word of caution,
+however: On some machines, such as mine running HP-UX 7.05,
+multi-character macros can not be called from other macros. So e.g.
+for a "ring" of macros to toggle between ":set wm=0" and ":set wm=8", I
+have to use a one-character name. Check it out on your machine, you may
+be luckier than I am.
+
+ Guenter Steinbach steinbac@hpl-opus.hpl.hp.com
+
+
+From roger@quantime.co.uk (Roger Phillips)
+Subject: Re: Good names for vi macros
+Date: 9 Feb 92 13:25:45 GMT
+Status: O
+
+In article <1992Feb4.121606.19333@news.cs.indiana.edu>,
+vdbuss@bigeye.cs.indiana.edu (Jan Van den Bussche) writes:
+> My question is: does anyone has suggestions concerning which names to choose
+> for naming macros?
+
+If you're using a vi which only allows single-character macro names,
+then you need to memorise which characters are available.
+E.g. I use v, then q for short-term macros.
+Some control-chars such as ^E, ^K may be ok,
+depending on your terminal, I guess.
+
+Fortunately, I always use vi's which allow 2-char names.
+The commands [[ and ]] (back/forward to next section/function),
+mean that the keys [ and ] have to be unbound on their own,
+so I can use [a [b ... [z and ]a ]b ... ]z for 52 different macros,
+even getting some sort of mnemonic naming sometimes :-)
+
+Anyone got any more ideas?
+
+--
+Roger Phillips roger@quantime.co.uk
+
+
+From mschee@bcarh600.bnr.ca (Michael SamChee)
+Subject: How do I ignorecase when using a TAGs file?
+Keywords: tags, ignorcase
+Date: 10 Feb 92 01:32:23 GMT
+Status: O
+
+I'm using a tags file in vi and would like it to ignore
+the case of the identifiers being searched for:
+
+e.g.,
+doing a on the identifiers TEMP, Temp, or temp should
+be recognized as the same identifier.
+
+Does anybody know how to overcome this problem?
+
+Michael.
+
+
+From vss@bigair.wpd.sgi.com (V.S.Senthil Kumar)
+Subject: Tabs and Blanks
+Date: 7 Feb 92 01:49:25 GMT
+Status: O
+
+
+
+what is the easy way to covert the tabs to appropriate number of blanks.
+
+personally, i fell sick of this tabs. (who cares about the file size?)
+[I use a tab stop of 4. but vi default is 8. so when ever some body brings
+my source file in the editor, it looks awful.]
+
+Does any body have a vi macro so that whenever i press
+tabs appropriate number of blanks are used.
+
+thanks,
+vs senthilkumar
+
+
+From peter@ferranti.com (peter da silva)
+Subject: Re: Tabs and Blanks
+Date: 9 Feb 92 19:46:28 GMT
+Status: O
+
+In article <golgj5k@dragon.wpd.sgi.com> vss@bigair.wpd.sgi.com (V.S.Senthil Kumar) writes:
+> what is the easy way to covert the tabs to appropriate number of blanks.
+
+Use an external program.
+
+> personally, i fell sick of this tabs. (who cares about the file size?)
+
+Personally, I like tabs (and not for file size).
+
+> [I use a tab stop of 4. but vi default is 8. so when ever some body brings
+> my source file in the editor, it looks awful.]
+
+That's why I like tabs. I use a tab stop of 2, 4, 6, or 8... switching on the
+fly as I edit my program.
+
+> Does any body have a vi macro so that whenever i press
+> tabs appropriate number of blanks are used.
+
+No, that's the hard way.
+--
+-- Peter da Silva, Ferranti International Controls Corporation
+-- Sugar Land, TX 77487-5012; +1 713 274 5180
+-- "Have you hugged your wolf today?"
+
+
+From weisen@daedalus.dcrt.nih.gov (Neil Weisenfeld)
+Subject: Re: Tabs and Blanks
+Date: 10 Feb 92 16:55:01 GMT
+Status: O
+
+
+In article <golgj5k@dragon.wpd.sgi.com> vss@bigair.wpd.sgi.com (V.S.Senthil Kumar) writes:
+
+
+ what is the easy way to covert the tabs to appropriate number of blanks.
+
+ personally, i fell sick of this tabs. (who cares about the file size?)
+ [I use a tab stop of 4. but vi default is 8. so when ever some body brings
+ my source file in the editor, it looks awful.]
+
+[stuff removed]
+
+
+What I do is this: set tabs to 8 and shift-width (sw) to the indent
+that I want to use (e.g. 4). To indent a level, type ctrl-t. To
+unindent a level, type ctrl-d.
+
+This will add the proper number of *tabs and spaces* to get you to
+where you want to go. It uses tabs for spacing out whatever the
+tabstop is set to, and uses spaces for fractions of a tabstop. You
+can also use the shift operators to unindent and indent regions.
+
+If you need to remove the tabs from a file, you can do this:
+
+:%!expand
+
+if your system has the expand command.
+
+
+--Neil
+
+
+--
+Neil I. Weisenfeld phone: (301) 402-2788
+Building 12A, Room 2046 uucp: uunet!nih-csl!weisen
+National Institutes of Health Internet: weisen@alw.nih.gov
+Bethesda, MD 20892
+
+
+From smarc@mas.UUCP (Marc Siegel)
+Subject: Re: Tabs and Blanks
+Date: 10 Feb 92 17:06:07 GMT
+Status: O
+
+vss@bigair.wpd.sgi.com (V.S.Senthil Kumar) writes:
+>
+>
+> what is the easy way to covert the tabs to appropriate number of blanks.
+>
+> personally, i fell sick of this tabs. (who cares about the file size?)
+> [I use a tab stop of 4. but vi default is 8. so when ever some body brings
+> my source file in the editor, it looks awful.]
+>
+> Does any body have a vi macro so that whenever i press
+> tabs appropriate number of blanks are used.
+>
+> thanks,
+> vs senthilkumar
+
+This is a simple problem.
+set the environment variable EXINIT as follows:
+
+EXINIT="map ^T :1,$ s;tab; ;g|se tabstop=4 "
+
+Replace the ^T with an actual control-T or whatever you want the
+sequence to be. Replace the word tab with an actual tab.
+You can put the appropriate number of spaces in the field following the
+tab.
+
+ Marc Siegel (smarc@mas.UUCP)
+ Emtronix Data Services Inc. (410) 486-2940
+ Baltimore, Maryland
+ smarc@mas.wb3ffv.AMPR.ORG <<New, Improved .sig Lite>>
+
+
+From jpr@jpradley.jpr.com (Jean-Pierre Radley)
+Subject: Re: Good names for vi macros
+Status: O
+
+In article <1992Feb9.132545.19653@quantime.co.uk> roger@quantime.co.uk (Roger Phillips) writes:
+>In article <1992Feb4.121606.19333@news.cs.indiana.edu>,
+>vdbuss@bigeye.cs.indiana.edu (Jan Van den Bussche) writes:
+>If you're using a vi which only allows single-character macro names,
+>then you need to memorise which characters are available.
+>E.g. I use v, then q for short-term macros.
+>Some control-chars such as ^E, ^K may be ok,
+>depending on your terminal, I guess.
+>
+>Fortunately, I always use vi's which allow 2-char names.
+>The commands [[ and ]] (back/forward to next section/function),
+>mean that the keys [ and ] have to be unbound on their own,
+>so I can use [a [b ... [z and ]a ]b ... ]z for 52 different macros,
+>even getting some sort of mnemonic naming sometimes :-)
+>
+>Anyone got any more ideas?
+
+Yeah. Use a vi which allows three-character names. The function keys on my
+ansi terminal emit three characters, and I map any of F1 through F12, and PgUp
+and PgDn too.
+--
+Jean-Pierre Radley Unix in NYC jpr@jpr.com jpradley!jpr CIS: 72160,1341
+
+
+From casterln@are.Berkeley.EDU (Gary Casterline)
+Subject: easy vi question: how to 'grep -v /r.e/'
+Date: 11 Feb 92 20:50:10 GMT
+Status: O
+
+This must me so obvious that I can't see it.
+Would some kind soul please show me how to
+do a negative search -- like 'grep -v string'.
+Go to the next line that does not have a specified
+regular expression.
+
+Thanks in advance.
+
+--
+Gary Casterline Agricultural & Resource Economics
+casterln@are.berkeley.edu 207 Giannini Hall
+(510) 642-5583 UC Berkeley, CA 94720
+
+
+From heroux@cemmva.cem.msu.edu (Brett J. Heroux)
+Subject: Re: easy vi question: how to 'grep -v /r.e/'
+Date: 12 Feb 92 01:40:19 GMT
+Status: O
+
+In article <kpgdo2INNkit@agate.berkeley.edu>, casterln@are.Berkeley.EDU (Gary Casterline) writes:
+>This must me so obvious that I can't see it.
+>Would some kind soul please show me how to
+>do a negative search -- like 'grep -v string'.
+>Go to the next line that does not have a specified
+>regular expression.
+
+>From within 'ex' try (the : is supplied)
+
+:g!/re/vi (or :v/re/vi and :v/re/vi. will put
+ that line in the middle of the screen)
+
+-from vi I'm stuck...
+
+
+Brett Heroux heroux@titan.cem.msu.edu
+
+
+From baillod@dip.eecs.umich.edu (Brad Baillod)
+Subject: vi question
+Date: 12 Feb 92 06:50:28 GMT
+Status: O
+
+I just have one small question about vi that my man command
+can't seem to answer. Please don't respond to this if you
+read it after Wednesday, February 12.
+
+I've used "vi bai*" and such to edit multiple files from
+the command line, and vi seems to read multiple files into
+its buffers, but I'll be damned if I can figure out a way
+to switch between buffers!
+
+It seems like I've tried every letter and control-letter
+sequence in both edit mode and command mode. I can type
+:q or ZZ to quit, or save and exit, etc. but it just keeps
+the same file on the screen and tells me I have "one more
+file to edit." My problem is switching to that file.
+
+Thanks for any help you can give me.
+
+Brad
+
+--
+Brad Baillod baillod@eecs.umich.edu
+
+From tchrist@convex.COM (Tom Christiansen)
+Subject: Re: vi question
+Date: 12 Feb 92 07:14:46 GMT
+>From the keyboard of baillod@dip.eecs.umich.edu (Brad Baillod):
+Status: O
+
+>I've used "vi bai*" and such to edit multiple files from
+>the command line, and vi seems to read multiple files into
+>its buffers, but I'll be damned if I can figure out a way
+>to switch between buffers!
+
+What you want is
+
+ :n
+
+I happen have ^N mapped to ":n +/^M" becuase that way I can say (tcsh alias)
+
+ alias vall 'vi +/!:1 `grep -l !:1 *.[^oa]`'
+
+and use ^N to get me through all the files at the right position.
+
+--tom
+
+
+From haegele@ibhinfo.hemminger-gdv.de (Frank Haegele)
+Subject: vi - redefine <TAB>-key with <BLANK><BLANK>
+Date: 11 Feb 92 18:17:02 GMT
+Status: O
+
+I'm using a VT420 terminal an I want to redefine the <TAB>-Key during
+an vi-session with two blanks.
+TERM=vt100
+
+I tried:
+
+ :set list<RETURN>
+ :map! ^I <RETURN>
+ ^^^- three blanks
+
+but it dosen't work.
+
+MfG Frank Haegele ( Hemminger GmbH )
+
+------------------------------------------------------------------------------
+Office: Frank Haegele, Hemminger GmbH, Rennstr.16, 7300 Esslingen
+Tel.: Germany +49 711, 311021 Voice, 311155 Fax
+Priv: Frank Haegele, Olgastr.50, 7300 Esslingen, Germany +49 711/3169139 Voice
+E-Mail: haegele@ibhinfo.Hemminger-GDV.DE haegele@delos.stgt.sub.org
+-------------------------------------------------------------------------------
+
+
+From ndh@bnr.co.uk (Neale D Hind)
+Subject: Re: vi question
+Date: 12 Feb 92 13:41:12 GMT
+Status: O
+
+In the referenced article baillod@dip.eecs.umich.edu (Brad Baillod) writes:
+>I just have one small question about vi that my man command
+>can't seem to answer. Please don't respond to this if you
+>read it after Wednesday, February 12.
+>
+>:q or ZZ to quit, or save and exit, etc. but it just keeps
+>the same file on the screen and tells me I have "one more
+>file to edit." My problem is switching to that file.
+>
+
+Use :n to move to the next file and :rewind to go back to the first file
+in the list.
+
+
++----------------------------------------------------------------+
+| Neale D. Hind | Email: ndh@bnr.co.uk |
+| Manager, Business Systems | Phone: +44 279 429531 x3613 |
+| BNR Europe Limited | Fax : +44 279 441551 |
+| London Road, HARLOW | ESN : 6-742-3613 |
+| Essex CM17 9NA, United Kingdom | Telex: 81151 STL HW G |
++----------------------------------------------------------------+
+
+
+From weisen@daedalus.dcrt.nih.gov (Neil Weisenfeld)
+Subject: Re: vi question
+Date: 12 Feb 92 17:31:34 GMT
+Status: O
+
+In article <1992Feb12.065028.4746@zip.eecs.umich.edu> baillod@dip.eecs.umich.edu (Brad Baillod) writes:
+>I just have one small question about vi that my man command
+>can't seem to answer. Please don't respond to this if you
+>read it after Wednesday, February 12.
+>
+>I've used "vi bai*" and such to edit multiple files from
+>the command line, and vi seems to read multiple files into
+>its buffers, but I'll be damned if I can figure out a way
+>to switch between buffers!
+>
+
+Brad,
+
+The :n and :rew answers that you got are correct, but I just wanted to make
+sure that you realized something. There is only *one* buffer in vi and you
+must save your changes to disk before switching between files. This is
+contrary to how multiple buffer editors like emacs work. You can't
+experiment as safely. I'm a die-hard vi fan, but sometimes find that using
+the VI emulation in emacs is handy. I always wind up coming back to the
+original, though.
+
+Also, if you get sick of the messages telling you that you need to write
+out the file before switching, set autowrite (aw). This will cause the
+buffers to be written to disk automatically when you switch from one file
+to another. You need to be more careful here, though. One last thing:
+CTRl-^ lets you switch to the ``previous file'' if there was one. This is
+a handy way to toggle between two files.
+
+
+Regards and happy editing,
+Neil
+
+
+--
+Neil I. Weisenfeld phone: (301) 402-2788
+Building 12A, Room 2046 uucp: uunet!nih-csl!weisen
+National Institutes of Health Internet: weisen@alw.nih.gov
+Bethesda, MD 20892
+
+
+From hm@fwi.uva.nl (Hans Mulder)
+Subject: Re: easy vi question: how to 'grep -v /r.e/'
+Date: 12 Feb 92 20:12:09 GMT
+Status: O
+
+In <0095603A.918A0900@cemmva.cem.msu.edu> heroux@cemmva.cem.msu.edu (Brett J. Heroux) writes:
+
+>In article <kpgdo2INNkit@agate.berkeley.edu>, casterln@are.Berkeley.EDU (Gary Casterline) writes:
+>>This must me so obvious that I can't see it.
+>>Would some kind soul please show me how to
+>>do a negative search -- like 'grep -v string'.
+>>Go to the next line that does not have a specified
+>>regular expression.
+
+>From within 'ex' try (the : is supplied)
+
+>:g!/re/vi (or :v/re/vi and :v/re/vi. will put
+> that line in the middle of the screen)
+
+But next time you try to switch to ex mode, you get thrown back into
+vi mode at the next line not matching /re/......
+
+>-from vi I'm stuck...
+
+Try
+
+:.,$v/re/a
+
+This jumps to the next line not matching /re/ and then complains that
+a: No such command from open/visual
+
+--
+Hans Mulder hansm@cs.kun.nl
+ hm@fwi.uva.nl
+
+
+From evh@genie.slhs.udel.edu (Troy Saville)
+Newsgroups: comp.binaries.ibm.pc.wanted
+Subject: Re: wanted: ms-dos vi
+Date: 13 Feb 92 05:16:41 GMT
+Status: O
+
+In article <1992Feb12.143027.1@sysjj.mdcbbs.com> lembark@sysjj.mdcbbs.com writes:
+>does anyone know of a vi for ms-dos (source/share/binary)? even a more-or-less
+>portable K&R source from UNIX! ANYTHING!
+>thanx
+
+I went through this a couple of months ago.
+Your best bet is to get ahold of the binaries or source code for
+a vi-clone called 'stevie'. I got it from an archive site.
+I managed to get it to compile under turbo C(++) and work.
+Its not a perfect 'vi'(as compared to a UNIX version), but i have found it
+to be good enough. It doesn't handle certain commands the same way
+as you would expect. Especially 'change' command.
+EX: 'cw'
+
+instead of placing a dollar sign at the end of the word it delete the word
+and puts you into insert mode.
+Oh yeah, its ram based so you can't edit really big files.
+
+If i get the chance i plan to make it handle 'cw' etc correctly,
+use memory above 1MB(extended, expanded whatever) and some other crap
+(maybe a keystoke files to recover changes, i don't know......)).
+
+
+I believe a commercial version is available from Mortice Kern Systems
+called MKS VI. Last time i checked, price was around 100$ at programmers
+paradise(or was it programmers connection), however, i got ahold of
+'stevie' and didn't order MKS vi.
+There is also an old version by custom system software(or something like that),
+but i beleive that they are no longer in business.
+I used this version and it was very good. as good as UNIX vi as far as
+i could tell. however, i bought a better graphics card and it wouldn't
+work so i'm using 'stevie' now.
+
+
+ evh@genie.slhs.udel.edu
+
+PS: I don't have the stevie source or binaries on the machine that my acct
+ is on so don't send requests for it. I don't expect to do any thing
+ with the stevie source code for months.
+--
+- Golf Discs and "MINI'S" bought and traded, DISC GOLF INFO ? - SEND EMAIL
+ evh@genie.slhs.udel.edu - T Saville - MENS OPEN PRO - PDGA #5399
+
+
+From tom@vpnet.chi.il.us (Tom Hansen)
+Subject: Re: vi question
+Date: 12 Feb 92 19:03:13 GMT
+Status: O
+
+In article <1992Feb12.065028.4746@zip.eecs.umich.edu> baillod@dip.eecs.umich.edu (Brad Baillod) writes:
+>I just have one small question about vi that my man command
+>can't seem to answer. Please don't respond to this if you
+>read it after Wednesday, February 12.
+>
+>I've used "vi bai*" and such to edit multiple files from
+>the command line, and vi seems to read multiple files into
+>its buffers, but I'll be damned if I can figure out a way
+>to switch between buffers!
+
+ I use ':e filename' to get the next file to edit, rather than the way
+ you seem to be doing it.
+ Once you have two files in the buffer the command ':e #'
+ will switch back and forth between the two. If you have more than
+ two then ':n' will get the next in sucession.
+
+--
+| Tom Hansen || "My beard grows to my toes. I never wears no |
+| tom@vpnet.chi.il.us || clothes. I wraps my hair around my bare, and |
+| "I yam what I yam" || down the road I goes." - Shel Silverstein |
+|______________________||___________________________________________________|
+
+
+Newsgroups: comp.unix.questions
+From buboo@alf.uib.no (Ove Ruben R Olsen)
+Subject: Re: vi - redefine <TAB>-key with <BLANK><BLANK>
+Date: Fri, 14 Feb 92 07:41:40 GMT
+
+Frank Haegele (haegele@ibhinfo.hemminger-gdv.de) writes:
+>I'm using a VT420 terminal an I want to redefine the <TAB>-Key during
+>an vi-session with two blanks.
+>TERM=vt100
+>
+>I tried:
+>
+> :set list<RETURN>
+> :map! ^I <RETURN>
+> ^^^- three blanks
+>
+>but it dosen't work.
+
+This solution works on version SVR3.1 of VI.
+
+First of all you need to escape the TAB key. Then you need to escape the
+SPACEs.
+
+:map! ^V^I ^V <RETURN>
+ ^^^- three blanks
+
+To get the CTRL's right:
+
+:map! <CTRL-V><CTRL-V><CTRL-V><CTRL-I> <CTRL-V><CTRL-V><SPC><SPC><SPC><CR>
+
+\Ruben.
+
+
+--
+ Ove Ruben R Olsen, Proffessional VI user. EMAIL: rubenro@viggo.blh.no
+ Also known as "The Gnarfer from Hell". (Registered character of ORRO.)
+ Maintaining the Largest VI/EX-STUFF Archive in the WORLD (alf.uib.no)
+ :wq!
+
+
+From scott@odin.unomaha.edu (Scott Ames)
+Subject: macro record and playback in vi?
+Keywords: vi macro
+Date: 15 Feb 92 13:51:48 GMT
+Status: O
+
+Is there a way to record macros and play them back in vi?
+I know about being able to execute commands that are in a named text
+buffer by doing @buffer_name, but it is a pain to get the commands in
+the buffer.
+
+Thanks,
+Scott Ames
+scott@odin.unomaha.edu
+
+
+From clewis@ferret.ocunix.on.ca (Chris Lewis)
+Subject: Re: Tabs and Blanks
+Date: 17 Feb 92 08:39:58 GMT
+Status: O
+
+In article <1992Feb17.061334.9585@robohack.UUCP> woods@robohack.UUCP (Greg A. Woods) writes:
+>In article <WEISEN.92Feb10115501@daedalus.dcrt.nih.gov> weisen@daedalus.dcrt.nih.gov (Neil Weisenfeld) writes:
+>> What I do is this: set tabs to 8 and shift-width (sw) to the indent
+>> that I want to use (e.g. 4). To indent a level, type ctrl-t. To
+>> unindent a level, type ctrl-d.
+
+This, incidentally, is exactly what I do.
+
+>EEEK! Wrong! :-)
+
+What's wrong with it Greg? You certainly see a lot of my code! ;-)
+We had a short chat about this earlier, in which you admitted ignorance
+of this technique - did you do any exploration beyond that conversation?
+
+>This makes the file very painful to edit/print/display on anything
+>with a tab-size of other than 8 characters, and difficult to edit with
+>any edit that properly deals with tabs characters in a normal fashion.
+
+Almost all hardware devices have 8 character tab widths, and relatively
+few hardware devices have settable tab stops. UNIX has no provision
+for setting tab width in serial drivers, or generically in hardware
+devices (other than settabs which few hardware devices support) and vi
+can only change tab width by doing the expansion itself.
+
+Having tab space as anything other than 8 is stupid, because *ONLY*
+vi can handle it. Your printer probably can't. Nor will your serial
+devices (and hence pg/more will be screwed) etc. And everyone else
+on earth will hate you. I certainly will.
+
+>Please set your shift-width and tabs to the same size! Then when you
+>want to squish everything down to fit on the screen/paper, you only
+>need to change the tab size, and when the indentation is important to
+>see, the tab size can be set up to a decent value (like 8 :-), and all
+>looks great!
+
+On the contrary, set tabs to 8. And set shift-width to what you
+want for code indentation. Then your code will look as you intended
+no matter what they display it on.
+
+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 ;-)
+
+>Yes, this makes tabs other than at the beginning of the code difficult
+>to line up, but they are no matter what you do.
+
+It's more than that. Screwing around with tab width screws up indentation
+even at the beginning of lines. And it can screw up any non-beginning
+formatting that doesn't have tabs just as easily.
+
+Ie: you have an if statement with multiple logical segments. It's
+nice to line things up, ala:
+
+ if (A ||
+ (B && D...........
+ E) ||
+ F
+
+ or
+ fprintf(stderr, "%s %s %d..."
+ arg1,
+ arg2
+
+Or, what will happen with this, even with tabs only at the beginning
+of lines?
+
+ if (something) { /* here we .... */
+ foo /* and do some more */
+
+
+etc. Screwing around with tab widths just destroys any attempts to
+make this sort of thing readable.
+
+(Greg has been known to concatenate nice&neat multiple line statements
+written by others into something that wraps several times. Just because
+he's on something that can display 100 columns. At the time.)
+
+[If you want to reply to this, please send mail. This machine doesn't
+get comp.editors - I got the original just because eci386 L1's me)
+--
+Chris Lewis; clewis@ferret.ocunix.on.ca; Phone: Canada 613 832-0541
+Psroff 3.0 info: psroff-request@ferret.ocunix.on.ca
+Ferret list: ferret-request@ferret.ocunix.on.ca
+
+
+From woods@robohack.UUCP (Greg A. Woods)
+Subject: Re: Tabs and Blanks
+Date: 17 Feb 92 06:13:34 GMT
+Status: O
+
+In article <WEISEN.92Feb10115501@daedalus.dcrt.nih.gov> weisen@daedalus.dcrt.nih.gov (Neil Weisenfeld) writes:
+>
+> What I do is this: set tabs to 8 and shift-width (sw) to the indent
+> that I want to use (e.g. 4). To indent a level, type ctrl-t. To
+> unindent a level, type ctrl-d.
+
+EEEK! Wrong! :-)
+
+This makes the file very painful to edit/print/display on anything
+with a tab-size of other than 8 characters, and difficult to edit with
+any edit that properly deals with tabs characters in a normal fashion.
+
+Please set your shift-width and tabs to the same size! Then when you
+want to squish everything down to fit on the screen/paper, you only
+need to change the tab size, and when the indentation is important to
+see, the tab size can be set up to a decent value (like 8 :-), and all
+looks great!
+
+Yes, this makes tabs other than at the beginning of the code difficult
+to line up, but they are no matter what you do.
+--
+ Greg A. Woods
+
+woods@{robohack,gate,eci386}.UUCP VE3-TCP UniForum Canada & Elegant Comm.
+(416) 443-1734 [home] (416) 595-5425 [work] Toronto, Ontario; CANADA
+
+
+From peter@ferranti.com (peter da silva)
+Subject: Re: Tabs and Blanks
+Date: 17 Feb 92 17:05:11 GMT
+Status: O
+
+In article <3157@ecicrl.ocunix.on.ca> clewis@ferret.ocunix.on.ca (Chris Lewis) writes:
+> Having tab space as anything other than 8 is stupid, because *ONLY*
+> vi can handle it.
+
+Having indent space as anything other than one tabstop is IMHO just as
+stupid, because you can't easily adjust the indenting of your code as you
+like it (say, using pr, or vi, or psroff|ghostscript, or whatever).
+
+I set tabstops to whatever is convenient for editing the code at hand,
+and leave them at 8 characters for prettifying the code so it looks nice
+on character-cell printers.
+
+> And everyone else on earth will hate you. I certainly will.
+
+You've seen my code. (now where have I heard that before?)
+
+> On the contrary, set tabs to 8. And set shift-width to what you
+> want for code indentation. Then your code will look as you intended
+> no matter what they display it on.
+
+Set tabs and shiftwidth to 8 for normal editing, and change them both
+together if you need more room. That way your code will look open and
+readable on hardcopy, but you can still edit it conveniently on narrow
+devices.
+
+> Futzing around with non-8 tab widths is a fools game. It can
+> turn mild-mannered system integrators into screaming maniacs.
+
+Futzing around with non-tabwidth indents is a fools game. It can
+turn mild mannered system integrators into screaming maniacs.
+
+> (Speaking as one who has screamed more than once ;-)
+
+(Speaking as one who has screamed more than once :-> )
+--
+-- Peter da Silva, Ferranti International Controls Corporation
+-- Sugar Land, TX 77487-5012; +1 713 274 5180
+-- "Have you hugged your wolf today?"
+
+
+From tchrist@convex.COM (Tom Christiansen)
+Subject: Re: Tabs and Blanks
+Date: 17 Feb 92 18:52:04 GMT
+Status: O
+
+>From the keyboard of peter@ferranti.com (peter da silva):
+:> On the contrary, set tabs to 8. And set shift-width to what you
+:> want for code indentation. Then your code will look as you intended
+:> no matter what they display it on.
+:
+:Set tabs and shiftwidth to 8 for normal editing, and change them both
+:together if you need more room. That way your code will look open and
+:readable on hardcopy, but you can still edit it conveniently on narrow
+:devices.
+:
+:> Futzing around with non-8 tab widths is a fools game. It can
+:> turn mild-mannered system integrators into screaming maniacs.
+:
+:Futzing around with non-tabwidth indents is a fools game. It can
+:turn mild mannered system integrators into screaming maniacs.
+
+I really don't see anything wrong with having shiftwidth be 4 and
+tabstop be 8. I don't like tabstop not to be 8 for printing purposes,
+and by having sw=4 makes code fit better, and it only takes two to
+make a tab. Some folks set sw=3, but then you can't >> and hit a real
+tab. Maybe that doens't matter.
+
+--tom
+
+
+From matthew@garfield.cs.mun.ca (Matthew J. Newhook)
+Subject: Re: Tabs and Blanks
+Date: 17 Feb 92 20:05:41 GMT
+Status: O
+
+tchrist@convex.COM (Tom Christiansen) writes:
+
+>From the keyboard of peter@ferranti.com (peter da silva):
+[snip]
+>I really don't see anything wrong with having shiftwidth be 4 and
+>tabstop be 8. I don't like tabstop not to be 8 for printing purposes,
+
+Assuming tabstop=4 what's wrong with expand -4 code.c | lpr ?
+
+Not that I ever print my code anymore anyway... I personally feel that
+it's never worth printing code. Isn't there some sort of heuristic
+that states the productivity of a programmer is inversely proportional to
+the number of times that the programmer prints the code?
+Of course, for students I guess this is a necessity.
+The only problem that I see in not having my tabstops set to 8 is that
+when I page my file (less, more, etc) it doesn't look right :(. However,
+I personally don't find this to be much of a problem.
+
+>and by having sw=4 makes code fit better, and it only takes two to
+>make a tab. Some folks set sw=3, but then you can't >> and hit a real
+>tab. Maybe that doens't matter.
+
+>--tom
+
+Matthew Newhook
+--
+----------------matthew@cs.mun.ca
+"Living in the limelight; the universal dream for those who wish to
+seem. Those who wish to be must put aside the alienation, get on with
+the fascination, the real relation, the underlying theme" - Rush
+
+
+From norrish@rata.vuw.ac.nz (Michael Norrish)
+Subject: vi ! command in non-interactive envt.
+Date: 18 Feb 92 06:34:01 GMT
+Status: O
+
+I have recently come to appreciate the wonders that can be performed
+with vi's rather elegant ! command. (For those reading who don't know,
+this takes a region of your buffer and feeds that to a specified shell
+command, with the output from that command replacing what was in the
+region).
+
+I am now curious about how this same task might be accomplished
+"non-interactively", (i.e. using sed or awk or something similar).
+Assume I want to run awk script silly.awk on lines 100-120 of my file.
+This would be my best stab at a solution, and I realise now that it's
+pretty ghastly:
+
+sed -n '100,120p' < myfile | awk -f silly.awk > /tmp/stage1.$$
+# now I have a file of the changed region. Now I have to sort of patch
+# this back into the original
+
+sed -n '1,99p' < myfile > /tmp/first_half.$$
+sed -n '121,$p' < myfile > /tmp/second_half.$$
+cat /tmp/first_half.$$ /tmp/stage1.$$ /tmp/second_half.$$ > myfile
+
+Voila! All done, but so kludgey. If anyone has any better ideas on how
+to accomplish this, I would be keen to see them, either here, or by
+mail.
+
+Thank you,
+Michael.
+
+--
+Michael Norrish. norrish@rata.vuw.ac.nz
+----------------Victoria University of Wellington---------------------
+"I can't believe *that*!" said Alice.
+"Can't you?" the Queen said in a pitying tone. "Try again: draw a long
+breath, and shut your eyes."
+
+
+From tchrist@convex.COM (Tom Christiansen)
+Subject: Re: vi ! command in non-interactive envt.
+Date: 18 Feb 92 06:13:37 GMT
+Status: O
+
+>From the keyboard of norrish@rata.vuw.ac.nz (Michael Norrish):
+:I have recently come to appreciate the wonders that can be performed
+:with vi's rather elegant ! command. (For those reading who don't know,
+:this takes a region of your buffer and feeds that to a specified shell
+:command, with the output from that command replacing what was in the
+:region).
+:
+:I am now curious about how this same task might be accomplished
+:"non-interactively", (i.e. using sed or awk or something similar).
+:Assume I want to run awk script silly.awk on lines 100-120 of my file.
+
+ #!/bin/awk -f
+ {
+ if (NR >= 100 && NR <= 120) {
+ # do the awk stuff
+ } else {
+ print
+ }
+ }
+
+or
+
+ #!/usr/bin/perl -p
+ if (100 .. 120) {
+ # do the awk stuff
+ }
+
+If what you want to do betwen lines 100 and 120 isn't an awk thing,
+you can open a pipe to another process. Make sure to close it when
+you're done so your output is in the right order. Your awk doesn't
+support close()? Get gawk. However, if you want to flush your pipe
+partway through, you're out of luck. Get the awk-to-perl translator. :-)
+
+
+--tom
+
+
+From tcm@tcm.austin.ibm.com (Tom McDonald)
+Subject: VI - Number of Lines
+Date: 14 Feb 92 16:11:19 GMT
+Status: O
+
+
+I've been trying to use vi in a 132x50 window. 132 columns works fine, but
+I can't get vi to use more than 24 lines.
+
+I've tried using 'vi -w50', ':set window=50', ':set scroll=50', to no avail.
+
+I'm using an xterm window on an RS/6000. Any ideas on what's causing the
+problem? Emailed answers preferred.
+
+
+Tom McDonald
+tcm@netmail.austin.ibm.com
+----------------------------------------------------------------------------
+My opinions are unrelated to IBM's
+
+
+From peter@ferranti.com (peter da silva)
+Subject: Re: Tabs and Blanks
+Date: 18 Feb 92 15:10:32 GMT
+Status: O
+
+In article <1992Feb17.185204.22850@news.eng.convex.com> tchrist@convex.COM (Tom Christiansen) writes:
+> [...] and by having sw=4 makes code fit better [...]
+
+I'd rather have the code open and readable, thanks. I was just working on
+some code that was not only sw=4, but looked like this:
+
+ if(...)
+ { int foo = bar;
+ ...
+ return spooge; }
+
+If I'm working on code and sw=8 makes it wrap I take it as a hint that I
+should consider refactoring it into smaller routines. If that doesn't look
+easy, I change ts and sw together while I'm working on it and use a wider
+printer.
+> make a tab. Some folks set sw=3, but then you can't >> and hit a real
+> tab. Maybe that doens't matter.
+>
+> --tom
+
+
+--
+-- 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)
+Subject: Re: Tabs and Blanks
+Date: 18 Feb 92 15:12:54 GMT
+Status: O
+
+In article <1992Feb17.200541.8661@garfield.cs.mun.ca> matthew@garfield.cs.mun.ca (Matthew J. Newhook) writes:
+> Not that I ever print my code anymore anyway... I personally feel that
+> it's never worth printing code. Isn't there some sort of heuristic
+> that states the productivity of a programmer is inversely proportional to
+> the number of times that the programmer prints the code?
+
+I guess that depends on whether you've got a laptop that's legible when
+you're desk-checking your code out by the pool. Sometimes one gets tired
+of cubing.
+--
+-- Peter da Silva, Ferranti International Controls Corporation
+-- Sugar Land, TX 77487-5012; +1 713 274 5180
+-- "Have you hugged your wolf today?"
+
+
+From hugh@BRL.MIL ( Hugh Dempsey)
+Newsgroups: comp.unix.questions
+Subject: Re: vi - redefine <TAB>-key with <BLANK><BLANK>
+Date: 18 Feb 92 13:18:07 GMT
+Status: O
+
+Hi,
+
+An easier solution is to either set shiftwidth or tabstop to 3.
+
+:set sw=3
+:set ts=3
+
+Best,
+
+Hugh
+hugh@brl.army.mil
+
+
+From anibal@wiley.EE.McGill.CA (JODORCOVSKY/ANIBAL GASTON/MR)
+Newsgroups: comp.unix.questions
+Subject: vi and terminal emulation vt102 ???
+Date: 18 Feb 92 18:51:11 GMT
+Status: O
+
+Hi!!
+
+ I am having a little problem when using VT102 emulation terminal.
+I am connecting with a modem (Supramodem 2400) to a Unix system, the
+comm software that I am using (Telix) supports VT102 emulation and
+I am using that one, having in my .login a set term=vt102.
+The problem is that when editing with vi, if I want to delete the
+last character of a line I sit on it and press x, but what happens is
+that 2 characters are deleted from the screen. I refresh the screen
+and the character that was before the last one reappears.
+A weird thing is that when I move the cursor to the left, the
+characters are erased from the screen but as soon as I refresh the
+screen they are there again.
+
+Has anyone know what is going on?
+
+Thanks a lot!
+
+
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
+= Anibal / anibal@honi.ee.mcgill.ca =
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
+
+
+From chris@visionware.co.uk (Chris Davies)
+Newsgroups: comp.unix.questions
+Subject: Re: vi - redefine <TAB>-key with <BLANK><BLANK>
+Date: 18 Feb 92 16:23:12 GMT
+Status: O
+
+Frank Haegele (haegele@ibhinfo.hemminger-gdv.de) writes:
+>I'm using a VT420 terminal an I want to redefine the <TAB>-Key during
+>an vi-session with two blanks.
+
+In article <1992Feb14.074140.3454@alf.uib.no> buboo@alf.uib.no (Ove Ruben R Olsen) writes:
+>To get the CTRL's right:
+>:map! <CTRL-V><CTRL-V><CTRL-V><CTRL-I> <CTRL-V><CTRL-V><SPC><SPC><SPC><CR>
+
+Ah! So that's how you do it.
+
+I've now got this set so that my TAB key becomes ^T (soft-indent), and
+I've set the shiftwidth (sw) to 4. This means I get 4-character
+indents which become tabs as and when possible...
+
+Thanks,
+
+Chris
+--
+ VISIONWARE LTD, 57 Cardigan Lane, LEEDS LS4 2LE, England
+ Tel +44 532 788858 x238. Fax +44 532 304676. Email chris@visionware.co.uk
+------------ "VisionWare: The home of DOS/SQL/UNIX/X integration" -----------
+
+
+From pct@LEO.Stanford.EDU (Peter C. Tam)
+Newsgroups: comp.unix.admin,comp.protocols.tcp-ip.ibmpc
+Subject: VI terminal type
+Date: 20 Feb 92 04:48:22 GMT
+Status: O
+
+Hi,
+ I try to install nansi termcap entry by:
+
+ . Entering nansi termcap entry into /etc/termcap w content roughly:
+ PC|nansi|IBM PC NANSI SYS :\
+ :al-\EE.......
+ ...
+ ... etc
+
+ . setenv TERM nansi
+
+ . tset
+
+ . vi filename
+
+ & vi complains it does not know terminal type "nansi". When I search
+ the /etc/termcap, it is there.
+
+ What is missing in the sequence?
+
+
+From woods@robohack.UUCP (Greg A. Woods)
+Subject: Re: Tabs and Blanks
+Summary: Trying not to scream, tear my hair out, and flame too much
+Date: Tue, 25 Feb 92 03:42:57 GMT
+Status: O
+
+In article <3157@ecicrl.ocunix.on.ca> clewis@ferret.ocunix.on.ca (Chris Lewis) writes:
+> What's wrong with it Greg? You certainly see a lot of my code! ;-)
+> We had a short chat about this earlier, in which you admitted ignorance
+> of this technique - did you do any exploration beyond that conversation?
+
+What's wrong with it is it makes any other indentation options
+*impossible* under software control without *changing* the file.
+
+> Having tab space as anything other than 8 is stupid, because *ONLY*
+> vi can handle it. Your printer probably can't. Nor will your serial
+> devices (and hence pg/more will be screwed) etc. And everyone else
+> on earth will hate you. I certainly will.
+
+Having tab size set to something other than 8 lets you read wide-bodied
+code on antique terminals without twisting your eyeballs trying to
+follow the wrapping.
+
+Then, when people with modern terminals, and/or wide-carriage (or
+small font) printers, get a look at the code, it appears in a readable
+form with nice deep and obvious indentation.
+
+This has absolutely nothing to do with what hardware or drivers can
+support what tab handling characteristics. Doing it right in the first
+place makes the actual tab size of no concern.
+
+> 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 ;-)
+
+Only if you have a layout style that'll turn some of us into screaming
+maniacs when we merely look at it, let alone try to read it.
+
+> etc. Screwing around with tab widths just destroys any attempts to
+> make this sort of thing readable.
+
+So, write it out "properly" so that anyone can read it regardless of
+their tab size setting, or use one tab character per indent and assume
+that the de-facto standard of 8-space tabs will keep your layout sane.
+--
+ Greg A. Woods
+
+woods@robohack.UUCP woods@Elegant.COM VE3-TCP UniForum Canada & Elegant Comm.
+(416) 443-1734 [home] (416) 595-5425 [work] Toronto, Ontario; CANADA
+
+
+From woods@robohack.UUCP (Greg A. Woods)
+Subject: Re: Tabs and Blanks
+Date: Tue, 25 Feb 92 03:53:26 GMT
+Status: O
+
+In article <1992Feb17.185204.22850@news.eng.convex.com> tchrist@convex.COM (Tom Christiansen) writes:
+> From the keyboard of peter@ferranti.com (peter da silva):
+> :Futzing around with non-tabwidth indents is a fools game. It can
+> :turn mild mannered system integrators into screaming maniacs.
+>
+> I really don't see anything wrong with having shiftwidth be 4 and
+> tabstop be 8. I don't like tabstop not to be 8 for printing purposes,
+> and by having sw=4 makes code fit better, and it only takes two to
+> make a tab. Some folks set sw=3, but then you can't >> and hit a real
+> tab. Maybe that doens't matter.
+
+What's wrong with it (and any other un-equal setting of the so-called
+shift-width and the tab size) is that you end up using both tabs and
+spaces to represent indentation, and the "level" of indentation cannot
+be determined by counting the number of indentation characters, nor
+can the amount of indentation per level be changed without changing
+the number of characters in the indentation, i.e. changing the file.
+
+By using *only* the tab character (i.e. *the* indentation character),
+the amount of indentation per level can be easily controlled by
+changing the the amount to space displayed per indentation character.
+No change to the file is necessary.
+
+How much simpler can you get?
+--
+ Greg A. Woods
+
+woods@robohack.UUCP woods@Elegant.COM VE3-TCP UniForum Canada & Elegant Comm.
+(416) 443-1734 [home] (416) 595-5425 [work] Toronto, Ontario; CANADA
+
+
+From Tom Christiansen <tchrist@convex.COM>
+Subject: Re: Tabs and Blanks
+Date: Tue, 25 Feb 1992 16:11:44 GMT
+Status: O
+
+>From the keyboard of woods@robohack.UUCP (Greg A. Woods):
+:In article <1992Feb17.185204.22850@news.eng.convex.com> tchrist@convex.COM (Tom Christiansen) writes:
+:> I really don't see anything wrong with having shiftwidth be 4 and
+:> tabstop be 8.
+:
+:What's wrong with it (and any other un-equal setting of the so-called
+:shift-width and the tab size) is that you end up using both tabs and
+:spaces to represent indentation, and the "level" of indentation cannot
+:be determined by counting the number of indentation characters, nor
+:can the amount of indentation per level be changed without changing
+:the number of characters in the indentation, i.e. changing the file.
+
+Indentation is for humans to read. If computers wish to do so, they
+are quite happy to convert the tabs to spaces before counting.
+
+--tom
+
+
+From mitchell@mdd.comm.mot.com (Bill Mitchell)
+Subject: Re: Tabs and Blanks
+Date: 25 Feb 92 19:14:29 GMT
+Status: O
+
+in comp.editors, tchrist@convex.COM (Tom Christiansen) said:
+
+
+>From the keyboard of woods@robohack.UUCP (Greg A. Woods):
+>:In article <1992Feb17.185204.22850@news.eng.convex.com> tchrist@convex.COM (Tom Christiansen) writes:
+>:> I really don't see anything wrong with having shiftwidth be 4 and
+>:> tabstop be 8.
+>:
+>:What's wrong with it (and any other un-equal setting of the so-called
+>:shift-width and the tab size) is that you end up using both tabs and
+>:spaces to represent indentation, and the "level" of indentation cannot
+>:be determined by counting the number of indentation characters, nor
+>:can the amount of indentation per level be changed without changing
+>:the number of characters in the indentation, i.e. changing the file.
+>
+>Indentation is for humans to read. If computers wish to do so, they
+>are quite happy to convert the tabs to spaces before counting.
+>
+
+and this may be a problem if your code is ever going to be maintained by
+some human who will use a different text editor than you use.
+
+--
+mitchell@mdd.comm.mot.com (Bill Mitchell)
+
+
+From Tom Christiansen <tchrist@convex.COM>
+Subject: Re: Tabs and Blanks
+Date: Tue, 25 Feb 1992 19:58:55 GMT
+Status: O
+
+>From the keyboard of mitchell@mdd.comm.mot.com (Bill Mitchell):
+:>Indentation is for humans to read. If computers wish to do so, they
+:>are quite happy to convert the tabs to spaces before counting.
+:
+:and this may be a problem if your code is ever going to be maintained by
+:some human who will use a different text editor than you use.
+
+Which is one of the reasons I keep my physical tabs set at 8, although
+shiftwidth and indentation level to 4. Any reasonable editor allows you
+to define simple code-shifting commands to arbitrary widths. It's not my
+fault if the person maintaining my code won't use a reasonable editor.
+
+--tom
+
+
+From buettneb@Informatik.TU-Muenchen.DE (Buettner)
+Subject: Bug in elvis?
+Date: Wed, 26 Feb 1992 07:45:09 GMT
+Status: O
+
+Hi folks,
+
+Yesterday I managed to kill elvis with a legal command (I believe).
+I wanted to replace <eol> from the current line to marker m with
+a comma and a blank. Actually I wanted to convert a short vertical
+list of items into a comma delimited list over two or three lines.
+
+With the following ex command I managed to hang my machine.
+
+:.,'ms/$/, /g
+
+I had marked a position below the cursor with mm before.
+
+Any ideas? Can anyone tell me what happens?
+
+
+Greetings,
+
+Bernhard Buettner
+
+
+From xiaofei@acsu.buffalo.edu (XiaoFei Wang)
+Subject: Re: Bug in elvis?
+Date: 26 Feb 92 14:29:15 GMT
+Status: O
+
+/* From the keyboard of buettneb@Informatik.TU-Muenchen.DE (Buettner) */:
+With the following ex command I managed to hang my machine.
+[with elvis ]
+:.,'ms/$/, /g
+
+This happens to me when I use elvis on msdos. The `solution' I found is
+to omit the `g' at the end, i.e. use
+:.,'ms/$/, /
+
+I do not know the address the author. Let us forward the problem to the
+author. Despite a few bugs, elvis is just great and I would like to see
+it to be perfect.
+
+--
+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 pgf@cayman.COM (Paul Fox)
+Subject: Re: Bug in elvis?
+Date: 26 Feb 92 17:46:29 GMT
+Status: O
+
+buettneb@Informatik.TU-Muenchen.DE (Buettner) writes:
+: With the following ex command I managed to hang my machine.
+:
+: :.,'ms/$/, /g
+:
+: Any ideas? Can anyone tell me what happens?
+
+how embarassing -- I smugly tried this with vile, thinking I'd fixed similar
+behavior before. Same bug. :-) At least I'm in good company.
+
+I suspect elvis is going infinite for the same reason vile does -- the /g
+on the end tries to redo the substitute for all non-overlapping matches, and
+the accounting of where we are and where we've matched gets a little fouled
+up when dealing with zero-length matches.
+
+paul fox, pgf@cayman.com
+(vile 3.9 is available for *BETA* testing at ftp.cayman.com, in pub/vile)
+--
+ paul fox, pgf@cayman.com, (617)494-1999
+ Cayman Systems, 26 Landsdowne St., Cambridge, MA 02139
+
+
+From steve@monu6.cc.monash.edu.au (Steve Balogh (+61 3 565 4747))
+Subject: Re: Tabs and Blanks
+Date: 26 Feb 92 00:59:54 GMT
+Status: O
+
+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
+
+----_--_-_-_--_-__-_------_-__---_-___-_----_-____-_-_--__-_--_--___-_-_-_--__-_
+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 peter@ferranti.com (peter da silva)
+Subject: Re: Tabs and Blanks
+Date: Tue, 25 Feb 1992 23:24:20 GMT
+Status: O
+
+> :[...] and the "level" of indentation cannot
+> :be determined by counting the number of indentation characters,
+
+In article <1992Feb25.161144.26962@news.eng.convex.com> tchrist@convex.COM (Tom Christiansen) writes:
+> Indentation is for humans to read. If computers wish to do so, they
+> are quite happy to convert the tabs to spaces before counting.
+
+Quite true. But what about the second point in the text you quoted? To
+wit:
+
+> :nor can the amount of indentation per level be changed without changing
+> :the number of characters in the indentation, i.e. changing the file.
+--
+-- Peter da Silva, Ferranti International Controls Corporation
+-- Sugar Land, TX 77487-5012; +1 713 274 5180
+-- "Have you hugged your wolf today?"
+
+
blob - /dev/null
blob + 8f891ab59a5671a2775c482ab3017627953b6ff0 (mode 644)
--- /dev/null
+++ comp.editors/ced.tips.6
+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.
+
+
blob - /dev/null
blob + ea5309a28061972eb0a429b8f5d8a483c58816be (mode 644)
--- /dev/null
+++ comp.editors/ced.tips.Inx
+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
+
blob - /dev/null
blob + e94ced0babf6fbd8986b256515dda0b37fd940fb (mode 644)
--- /dev/null
+++ comp.editors/cmdline
+
+
+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
+--
blob - /dev/null
blob + 4c5b0702c1e3bbef81cfe8c2d55e12431af40bfb (mode 644)
--- /dev/null
+++ comp.editors/cols
+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-)
+
+
+
blob - /dev/null
blob + a5a842acf40627b6c590a48027ebdf34a2d949db (mode 644)
--- /dev/null
+++ comp.editors/columedit
+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
+
+
blob - /dev/null
blob + 1d42b0f5fc35ec284be30d2feb169fb1451c6eaf (mode 644)
--- /dev/null
+++ comp.editors/counter
+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
\ No newline at end of file
blob - /dev/null
blob + 4c2574ca1440030540e6915980d8ae2b7d331bc3 (mode 644)
--- /dev/null
+++ comp.editors/countwords
+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
+
+
blob - /dev/null
blob + 9be51019c431e113daaf18140bb518855903bb89 (mode 644)
--- /dev/null
+++ comp.editors/crlf
+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
\ No newline at end of file
blob - /dev/null
blob + 0b54f4aa537b24dff88606e49ce87f2941d4e71e (mode 644)
--- /dev/null
+++ comp.editors/cshline
+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
+---------------------------------------------------------------------
+
blob - /dev/null
blob + 211b9be6ce85299f3bd14963b0e22235d7e8e65a (mode 644)
--- /dev/null
+++ comp.editors/ctrl
+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
\ No newline at end of file
blob - /dev/null
blob + f27b59f949cec77fc20746620bbaae73d4a58599 (mode 644)
--- /dev/null
+++ comp.editors/currfn
+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
\ No newline at end of file
blob - /dev/null
blob + 4e13a008399ffabba14c88bc4497a7d66b30e380 (mode 644)
--- /dev/null
+++ comp.editors/cutpaste
+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
+
blob - /dev/null
blob + 9d1385243f522d77316660f9e2a0362da5786756 (mode 644)
--- /dev/null
+++ comp.editors/demyst
+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
\ No newline at end of file
blob - /dev/null
blob + 72575900858d77f753c4dd4a0cf22b70ad9c05a2 (mode 644)
--- /dev/null
+++ comp.editors/executing
+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
\ No newline at end of file
blob - /dev/null
blob + 89f1f833ac9c642d50e238c47a26b6ecf9b759a3 (mode 644)
--- /dev/null
+++ comp.editors/history
+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
+
+
blob - /dev/null
blob + 3d85db51911a7589c6bf2ad81a99c418578aed01 (mode 644)
--- /dev/null
+++ comp.editors/insert
+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
\ No newline at end of file
blob - /dev/null
blob + 4fe4f006ea9bee9a745afda9e935e46e160bc95f (mode 644)
--- /dev/null
+++ comp.editors/macrolimits
+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
\ No newline at end of file
blob - /dev/null
blob + b0476c9ba11cc58436ff502a9f63fba0b3ff1ea9 (mode 644)
--- /dev/null
+++ comp.editors/mapping
+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 *
+**********************************************************
\ No newline at end of file
blob - /dev/null
blob + 8ce37554fa54f9b6e82d5a0eb5fa20e071bddb3d (mode 644)
--- /dev/null
+++ comp.editors/mapspace
+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
\ No newline at end of file
blob - /dev/null
blob + 1f86d0ed8cf2ab2bc50d132154e5455e8f2f3586 (mode 644)
--- /dev/null
+++ comp.editors/maptab
+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
\ No newline at end of file
blob - /dev/null
blob + 698d371745ddbe88b0f3a89b7a431ffc58940eda (mode 644)
--- /dev/null
+++ comp.editors/misc
+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
\ No newline at end of file
blob - /dev/null
blob + 960985f9ae95d41699a3a024be9dd337af57ed2e (mode 644)
--- /dev/null
+++ comp.editors/modeline
+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
blob - /dev/null
blob + d24e49ff29579cd0f44ad1bbfa8c4ee1c4a49719 (mode 644)
--- /dev/null
+++ comp.editors/multiple
+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
\ No newline at end of file
blob - /dev/null
blob + 8ebd03744f4f08a918dbd98c1b47bb350d55ed9f (mode 644)
--- /dev/null
+++ comp.editors/nthoccurance
+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.
\ No newline at end of file
blob - /dev/null
blob + 7b9b8ce92c77ba2e9cb15a710829185d2970a184 (mode 644)
--- /dev/null
+++ comp.editors/octal
+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
\ No newline at end of file
blob - /dev/null
blob + b7c3e8448d5ce37cdc778b7f8f229119ea42524d (mode 644)
--- /dev/null
+++ comp.editors/paragraph
+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
\ No newline at end of file
blob - /dev/null
blob + a161d76f2225d5476a19e30f52bea8ae584bc813 (mode 644)
--- /dev/null
+++ comp.editors/parawrap
+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
\ No newline at end of file
blob - /dev/null
blob + 2d3c8ed2ae30bce13bc0fb23dbc67495afa680b2 (mode 644)
--- /dev/null
+++ comp.editors/readin
+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
\ No newline at end of file
blob - /dev/null
blob + a5f3567dcc760f3de872c0a10663676ed0611819 (mode 644)
--- /dev/null
+++ comp.editors/regexp
+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
\ No newline at end of file
blob - /dev/null
blob + c79e5ba26f4ae5b7a25d621210488a03fee8e307 (mode 644)
--- /dev/null
+++ comp.editors/repeatcmd
+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
\ No newline at end of file
blob - /dev/null
blob + 90680f2ba9dc5e217f90622649183af96bf40afd (mode 644)
--- /dev/null
+++ comp.editors/replace
+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
+
+
blob - /dev/null
blob + 0cd548dcaa786bb307046f4559769df8687654d2 (mode 644)
--- /dev/null
+++ comp.editors/sandr
+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
blob - /dev/null
blob + 7de138f54f8eeb06b3b09d9b36aaec41770cac70 (mode 644)
--- /dev/null
+++ comp.editors/spellcheck
+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
\ No newline at end of file
blob - /dev/null
blob + 3663ee4869f07d63bd533c43ead8e8ffcec74d75 (mode 644)
--- /dev/null
+++ comp.editors/startup
+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
blob - /dev/null
blob + 67c62f18080419e15780bebb4dfd7f7adfebfe51 (mode 644)
--- /dev/null
+++ comp.editors/tab2space
+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
\ No newline at end of file
blob - /dev/null
blob + 15323880f6a39ca57e936b514ca856d61c5df42a (mode 644)
--- /dev/null
+++ comp.editors/tabing
+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
\ No newline at end of file
blob - /dev/null
blob + 532456e9b362773f704f78a2e60379aebcc07856 (mode 644)
--- /dev/null
+++ comp.editors/tabs
+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
+
+
blob - /dev/null
blob + 6c95444d32c99267d8ec4e24ecfdd7c5dfc77d54 (mode 644)
--- /dev/null
+++ comp.editors/termcap
+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*
+*
+====================
\ No newline at end of file
blob - /dev/null
blob + 47a1769a561618bd532893cc7a9374920db04174 (mode 644)
--- /dev/null
+++ comp.editors/toodanger
+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
\ No newline at end of file
blob - /dev/null
blob + 7a6dd99998a2c0906860aa5b04c91b25a97d573b (mode 644)
--- /dev/null
+++ comp.editors/toomuch
+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
\ No newline at end of file
blob - /dev/null
blob + 5216f21751214cb9e038f4cd7933542f7c7bfa7c (mode 644)
--- /dev/null
+++ comp.editors/transfer
+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
\ No newline at end of file
blob - /dev/null
blob + 04a43574501f5313d73f88ae254fcc8eb47627ba (mode 644)
--- /dev/null
+++ comp.editors/undo
+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
+
+
blob - /dev/null
blob + 11e3e37d5b5b9a7a9071003d9b77800b8ec2ec9c (mode 644)
--- /dev/null
+++ comp.editors/vim
+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
+
+
blob - /dev/null
blob + 31336e21de048b5687a92f3fa9a86851a486ae4d (mode 644)
--- /dev/null
+++ comp.editors/vs.emacs
+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) %
+
+
blob - /dev/null
blob + b2ee7c54dfaec9b980eef4e292ac4d55d2db58d6 (mode 644)
--- /dev/null
+++ comp.editors/windowrez
+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
\ No newline at end of file
blob - /dev/null
blob + 419af625798ab40b800b373cf7e9bc8ef2813a12 (mode 644)
--- /dev/null
+++ comp.editors/wordwrap
+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
\ No newline at end of file
blob - /dev/null
blob + 582305c6da6987990fb423d98b080a07c2770b29 (mode 644)
--- /dev/null
+++ comp.editors/writeout
+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
\ No newline at end of file
blob - /dev/null
blob + 8a888af6a0aead8e20c332c55669538528acff23 (mode 644)
--- /dev/null
+++ comp.editors.EDS
+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.
+
+
+--------------
+
+
+
blob - /dev/null
blob + 8f498f2c1dfe2fd95bea84c7bc71bd28e4c5feef (mode 644)
--- /dev/null
+++ comp.editors.FAQ
+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).
+
+
+
blob - /dev/null
blob + 60198fecd4848601b24dc8fd9bc99d1df3f86f64 (mode 644)
--- /dev/null
+++ comp.editors.PNT
+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.
blob - /dev/null
blob + b432ac92b9304b83788964f3b56481c6e9459bf2 (mode 644)
--- /dev/null
+++ comp.editors2
+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
+
blob - /dev/null
blob + 7a0a6b9761d87541d4dcbe74ca145d3f3911396f (mode 644)
--- /dev/null
+++ comp.editors3
+[... 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.
+
+
blob - /dev/null
blob + 5920d225ab5f20e5a81339f0d78f0b769d4d3a0b (mode 644)
Binary files /dev/null and docs/132.Z differ
blob - /dev/null
blob + 35d9de868662fbe1ad7e9a94b5b5040dd6d9f162 (mode 644)
Binary files /dev/null and docs/POINTERS.Z differ
blob - /dev/null
blob + 2de148270942ce5d775d0b9964ab3a111fca9037 (mode 644)
Binary files /dev/null and docs/advocasy.Z differ
blob - /dev/null
blob + fd8d2ea7e4577daacad43b322f90a738f7680984 (mode 644)
Binary files /dev/null and docs/apwh.ms.Z differ
blob - /dev/null
blob + 247c4cc90054cd8ae089d105902328051caa035b (mode 644)
--- /dev/null
+++ docs/arrowkwys
+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
+
blob - /dev/null
blob + ffebf57a1be72305d31cb25747a7362ddd92dcf4 (mode 644)
Binary files /dev/null and docs/bed.tar.Z differ
blob - /dev/null
blob + 59a4b09aa3e508ab71b7c29444b3bd460a31a40e (mode 644)
Binary files /dev/null and docs/beginers.Z differ
blob - /dev/null
blob + 1043b08c2d5f66a06d0f6e7f30f9797741c7339c (mode 644)
Binary files /dev/null and docs/books.Z differ
blob - /dev/null
blob + bac24ca5662c1c67f54d331efc8407e62ee40d9e (mode 644)
Binary files /dev/null and docs/bugs.Z differ
blob - /dev/null
blob + e8c268db84f1ca87fb425340d38f92e534aa4d9a (mode 644)
Binary files /dev/null and docs/capitalize.Z differ
blob - /dev/null
blob + 8babf6ea69e293335f50bc1ba584bb61e554b5f0 (mode 644)
Binary files /dev/null and docs/card.tex.Z differ
blob - /dev/null
blob + 67ed54e3abd4c2f5e83a45b7b59a92600a773772 (mode 644)
--- /dev/null
+++ docs/caseconv
+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
\ No newline at end of file
blob - /dev/null
blob + 3a9556b535db2f13e807d8dca117f826a39633b0 (mode 644)
--- /dev/null
+++ docs/casesr
+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
+
blob - /dev/null
blob + c8abe9b78054afc0e44e085a47fdcb46ec8f58ec (mode 644)
Binary files /dev/null and docs/chars.Z differ
blob - /dev/null
blob + 404509b9c06e7c1e9246b723f7b43dd780a3aac3 (mode 644)
Binary files /dev/null and docs/chars.tex.Z differ
blob - /dev/null
blob + 39193c9a8539bc3e1041eaeb2f39e449e5ae3895 (mode 644)
Binary files /dev/null and docs/ckv.Z differ
blob - /dev/null
blob + 03c132dc72dd91e257d3f284da4284753244f098 (mode 644)
Binary files /dev/null and docs/ckv2.Z differ
blob - /dev/null
blob + 770aa2712781722233fe263122614304c5c31174 (mode 644)
Binary files /dev/null and docs/course.Z differ
blob - /dev/null
blob + 6045832cfea992515b1d96f4e09a3002e1a334f9 (mode 644)
Binary files /dev/null and docs/course.tar.Z differ
blob - /dev/null
blob + b065804fe1b7eb563186d8dfaaf5daca78931b43 (mode 644)
Binary files /dev/null and docs/crypt.Z differ
blob - /dev/null
blob + 27b0149dbdf545c4bfd8e3e8c3a633e95441c4e7 (mode 644)
Binary files /dev/null and docs/ctags.Z differ
blob - /dev/null
blob + 5ed7e168709b0bb210adb32c9899915dd54bd5ed (mode 644)
Binary files /dev/null and docs/e2.tar.Z differ
blob - /dev/null
blob + 257647b951956a741cbebf9d3333a9042c216029 (mode 644)
Binary files /dev/null and docs/editech.1.Z differ
blob - /dev/null
blob + 8a741865dd832fbdb334436049a9b23a484c3f9c (mode 644)
Binary files /dev/null and docs/editech.2.Z differ
blob - /dev/null
blob + d5572dcabb40447d91df1e9f3a27aed2a5c5f7a5 (mode 644)
Binary files /dev/null and docs/editech.3.Z differ
blob - /dev/null
blob + 8b6c156adb10934a798db649b680db289a150594 (mode 644)
Binary files /dev/null and docs/editech.4.Z differ
blob - /dev/null
blob + 8498b9030ab85153ab55458ba79fb21fd6f7c829 (mode 644)
Binary files /dev/null and docs/editech.5.Z differ
blob - /dev/null
blob + e5a192b3bc7c136e099a4d7457bc30c9ebb41256 (mode 644)
Binary files /dev/null and docs/editech.books.Z differ
blob - /dev/null
blob + 79c073377d41fd4e85719261e2e701c15d3553a7 (mode 644)
Binary files /dev/null and docs/elvis.Z differ
blob - /dev/null
blob + 0b1594df7a00c9bdd5d87aa81cf7d84c37b1ca16 (mode 644)
Binary files /dev/null and docs/ex.changes.Z differ
blob - /dev/null
blob + a1257d92efc27e45873e049bebd1e22ce5116066 (mode 644)
Binary files /dev/null and docs/ex.fix.Z differ
blob - /dev/null
blob + af108f280a72a03c00ff69dd04b77b93a3a0071e (mode 644)
Binary files /dev/null and docs/ex.reference.Z differ
blob - /dev/null
blob + 36e0227de063c1c9f2ed660421e00ba38fa51c91 (mode 644)
Binary files /dev/null and docs/ex.summary.Z differ
blob - /dev/null
blob + bfe37f3778d87dc6e68453e11cc8a14479148467 (mode 644)
Binary files /dev/null and docs/formating.Z differ
blob - /dev/null
blob + 4af945b1123a4af1aa0fb1458eff18bd63d7e024 (mode 644)
Binary files /dev/null and docs/globaldelete.Z differ
blob - /dev/null
blob + 6f63fff9dd7adcd2984c0f5945f010d6d63f8d9d (mode 644)
Binary files /dev/null and docs/help.Z differ
blob - /dev/null
blob + 59f971485fcd8476dc6df9edcc3ad5899b66ba90 (mode 644)
Binary files /dev/null and docs/innforing.Z differ
blob - /dev/null
blob + eb2293a57bff5cf8299a17197455edc80303fa22 (mode 644)
Binary files /dev/null and docs/intro.Z differ
blob - /dev/null
blob + 56efa770eaa3bed29067fbd592a6588bb3cf3be4 (mode 644)
Binary files /dev/null and docs/intro.ps.Z differ
blob - /dev/null
blob + e16f6392b98c4b72f0d7bbd902ac559997c31a05 (mode 644)
Binary files /dev/null and docs/jl.ex.ref.Z differ
blob - /dev/null
blob + d3e6b890d0023dab5e400829f9fbb5d5afc54080 (mode 644)
Binary files /dev/null and docs/keybind.Z differ
blob - /dev/null
blob + 37d4579eb960c0618375f0bb480f990aeaa7332d (mode 644)
Binary files /dev/null and docs/keymapings.Z differ
blob - /dev/null
blob + 37fa545697a1d97cdf9704e4b87c89b06f00992e (mode 644)
Binary files /dev/null and docs/keys.Z differ
blob - /dev/null
blob + 80259d6db252e67ac08416332b60959178f8b80d (mode 644)
Binary files /dev/null and docs/love.Z differ
blob - /dev/null
blob + 05a86e2253b71103bcd0e5001f4b8fe4bfe5a578 (mode 644)
Binary files /dev/null and docs/lvi.tar.Z differ
blob - /dev/null
blob + a04bb85aba753efdf35a07253051d59215ff3908 (mode 644)
Binary files /dev/null and docs/macroDoc.tar.Z differ
blob - /dev/null
blob + a3f73e38dfba238e18afa5fda7cf05400777ff8e (mode 644)
Binary files /dev/null and docs/macros.Z differ
blob - /dev/null
blob + 8d63b0afb0ad97cb09aa9e1cb198b2efc466daec (mode 644)
Binary files /dev/null and docs/macrotips.Z differ
blob - /dev/null
blob + bd7acda47d3db8d49493be54e33f6b4aeab439b3 (mode 644)
Binary files /dev/null and docs/man.tut.Z differ
blob - /dev/null
blob + e4680940066962b55839ebcbcb8912c685a8d814 (mode 644)
Binary files /dev/null and docs/mks.ant.Z differ
blob - /dev/null
blob + eb9e3b006ce0109a1bb170e5715c023142fb498d (mode 644)
Binary files /dev/null and docs/motd.tar.Z differ
blob - /dev/null
blob + 893f74e73519042f46feed801d3b205acee243aa (mode 644)
Binary files /dev/null and docs/move.Z differ
blob - /dev/null
blob + 88cbf2c59ceaeca102ea4b775d51a7eacdeb5a16 (mode 644)
Binary files /dev/null and docs/multfile.Z differ
blob - /dev/null
blob + 4f782c8979fb043d1bae1c8479bfbd6a82cb5ba0 (mode 644)
Binary files /dev/null and docs/mvi.c.Z differ
blob - /dev/null
blob + e4e16fac332295c6e3612fd8898f45bef46081b7 (mode 644)
Binary files /dev/null and docs/nvi.tar.Z differ
blob - /dev/null
blob + 7a13fb094d85593cd26c4611e4c8424f1da23d68 (mode 644)
Binary files /dev/null and docs/online-101.tar.Z differ
blob - /dev/null
blob + a147e750cd8e9775f6b8b3701b26cc1ddca0bd13 (mode 644)
Binary files /dev/null and docs/online-200.tar.Z differ
blob - /dev/null
blob + 512a2eb538844b74ab14f451d09d6554734f326f (mode 644)
Binary files /dev/null and docs/passwd.Z differ
blob - /dev/null
blob + 1d84ec0de42c3d2b5bd448ada0399eba6b9524e6 (mode 644)
Binary files /dev/null and docs/passwd.fix.Z differ
blob - /dev/null
blob + 6a3dd2b5e3919fff6e7e3ab8cb5e0055eb649ff0 (mode 644)
Binary files /dev/null and docs/patch.Z differ
blob - /dev/null
blob + 90a5f91864dd90d0047bbe59cf8a35f2bc9ff7b3 (mode 644)
Binary files /dev/null and docs/quick.Z differ
blob - /dev/null
blob + 6e2905e77e90ad3c22c7329a08cc704bb41f14ec (mode 644)
Binary files /dev/null and docs/rcut.tar.Z differ
blob - /dev/null
blob + 3948b7298e87cbdbaa753e4c81bcc3afdd7a4464 (mode 644)
Binary files /dev/null and docs/ref.Z differ
blob - /dev/null
blob + 6f22f93dc3561fa8aba52413a50a46beb93d3745 (mode 644)
Binary files /dev/null and docs/refchrt.Z differ
blob - /dev/null
blob + 6174f5cc8b8c0250ff85d1dabacab991df88ee3f (mode 644)
Binary files /dev/null and docs/reference.Z differ
blob - /dev/null
blob + a5cddcd21682684b1104f02e221394f15a2df0af (mode 644)
Binary files /dev/null and docs/reference.ms.Z differ
blob - /dev/null
blob + 3512de04459648529e803bc8737a3bcb72a7629f (mode 644)
Binary files /dev/null and docs/sections.Z differ
blob - /dev/null
blob + 62286c9cd0122207ee053165f79d964c4cc58c11 (mode 644)
Binary files /dev/null and docs/shell-101.BetaA.Z differ
blob - /dev/null
blob + 6f2d00c7a5100dbb2f987e7d7cb0da01010dfc52 (mode 644)
Binary files /dev/null and docs/sigint.fix.Z differ
blob - /dev/null
blob + 1ddc36d51084b32ec11206f9002e746f69cedfaf (mode 644)
Binary files /dev/null and docs/song.Z differ
blob - /dev/null
blob + a700a70619a56346e46e7af1114ceb2d95236d27 (mode 644)
Binary files /dev/null and docs/ss.qrf.Z differ
blob - /dev/null
blob + bf9c409722964583d892cfcbac7d822cc470b416 (mode 644)
Binary files /dev/null and docs/summary.Z differ
blob - /dev/null
blob + fa74b64e72e41841e63b34bf4aa4f7f313d45973 (mode 644)
Binary files /dev/null and docs/tabd.Z differ
blob - /dev/null
blob + af1e8047be5101b8ec85b8ad9fe4fbba64af371f (mode 644)
Binary files /dev/null and docs/tagStack.Z differ
blob - /dev/null
blob + 97d899b2decfccf02c0accd85ea1d6e6fb62fa1e (mode 644)
Binary files /dev/null and docs/tags.Z differ
blob - /dev/null
blob + 6ff465cf151572f0907967232bc1555f9a84da49 (mode 644)
Binary files /dev/null and docs/terse.help.Z differ
blob - /dev/null
blob + 4a825daf04f0121051ac8f0a9171b9de8210bf66 (mode 644)
Binary files /dev/null and docs/tips.Z differ
blob - /dev/null
blob + 586e13fb9214a280936a5d21417b49c7836f86b4 (mode 644)
Binary files /dev/null and docs/tutor.Z differ
blob - /dev/null
blob + ec3cc7deb43657a2d7b071d4f18246f57e7b20a6 (mode 644)
Binary files /dev/null and docs/tutor.tar.Z differ
blob - /dev/null
blob + 67c962f855288108ce3ed3cd8b06ffd397860008 (mode 644)
Binary files /dev/null and docs/tutor.tex.Z differ
blob - /dev/null
blob + 5258bd53ca53646035bc589924cdd8d6cc6ff2d8 (mode 644)
Binary files /dev/null and docs/ucb.tar.Z differ
blob - /dev/null
blob + b7ce6dc8e91b220a6e690b724a9889f553c29e8d (mode 644)
Binary files /dev/null and docs/vi.1.Z differ
blob - /dev/null
blob + b7a477d0a0ead511e352314eaf616a0759af7611 (mode 644)
Binary files /dev/null and docs/vifs.tar.Z differ
blob - /dev/null
blob + b5f36cec575236881d4c6c4a84ccb63f101b31be (mode 644)
Binary files /dev/null and docs/vilearn.tar.Z differ
blob - /dev/null
blob + 4d9b01496e6d5e2fce18e92c90a065f531910e67 (mode 644)
Binary files /dev/null and docs/vms.Z differ
blob - /dev/null
blob + 67ae2839eaa93e1f6985375a38edba39a83448b4 (mode 644)
Binary files /dev/null and macros/README.Z differ
blob - /dev/null
blob + cd591bf24b01529f39508d10293f6b994aa04e2b (mode 644)
Binary files /dev/null and macros/ball.tar.Z differ
blob - /dev/null
blob + 6fb4f251c5633e571bc3a11333600a0074b486c0 (mode 644)
Binary files /dev/null and macros/blocks.Z differ
blob - /dev/null
blob + bf59566978639ed04ebaff209d37941749610a6b (mode 644)
Binary files /dev/null and macros/blocks.d.Z differ
blob - /dev/null
blob + e23d2086e7d679b0b2d4500fed63fd40a6388027 (mode 644)
Binary files /dev/null and macros/c.template.Z differ
blob - /dev/null
blob + 0b9e67b4498e6aff71cdbd89597b6890d21fa97d (mode 644)
Binary files /dev/null and macros/case.Z differ
blob - /dev/null
blob + b033e7bebb4e4dd76b2b656fedd4588d2673ea70 (mode 644)
Binary files /dev/null and macros/case.word.Z differ
blob - /dev/null
blob + 9e06f822ef37039916dbbd7be62750d033dafd99 (mode 644)
Binary files /dev/null and macros/case.word2.Z differ
blob - /dev/null
blob + 09410eed816c51fcc977e810025557f904c8e1b2 (mode 644)
Binary files /dev/null and macros/cases.d.Z differ
blob - /dev/null
blob + f091e747ae521d3031a7cbf1ed020a639ba01b7a (mode 644)
Binary files /dev/null and macros/caseword.Z differ
blob - /dev/null
blob + de9084eccc12abc798c2e1d5fa24018a09121eb0 (mode 644)
Binary files /dev/null and macros/center.Z differ
blob - /dev/null
blob + b80d791ebc39b141307bb1e8412faae2abc3eff5 (mode 644)
Binary files /dev/null and macros/cil.tc.Z differ
blob - /dev/null
blob + e252e9c038a704044038d63a672767c50d86eaf9 (mode 644)
Binary files /dev/null and macros/cmacros.Z differ
blob - /dev/null
blob + f835e054d168f80ba66e9216d26d2a4e02954add (mode 644)
Binary files /dev/null and macros/commentC.tar.Z differ
blob - /dev/null
blob + e91732d49c39f67b68f18bf97b5781acfcfc978c (mode 644)
Binary files /dev/null and macros/complete.Z differ
blob - /dev/null
blob + 4b77e4b3ca053b6f02d56960fb3bb21b31a81df1 (mode 644)
Binary files /dev/null and macros/complete.ext.Z differ
blob - /dev/null
blob + 257629b26be05cc8f048592711ff8ae7eb6066df (mode 644)
Binary files /dev/null and macros/complete.new.Z differ
blob - /dev/null
blob + c4888501b4b3a670302096791127f30b94d03cd6 (mode 644)
Binary files /dev/null and macros/cvi.Z differ
blob - /dev/null
blob + 9ece5f6351f4e638a355135b06396bc017cbccab (mode 644)
Binary files /dev/null and macros/emacs.style.Z differ
blob - /dev/null
blob + beb96b7f63d316a18524eb5cfb737ec535508f14 (mode 644)
Binary files /dev/null and macros/evi.tar.Z differ
blob - /dev/null
blob + cfd3a7d99d9f2b828ffe8c34e96a19a4b2448b89 (mode 644)
Binary files /dev/null and macros/execute.Z differ
blob - /dev/null
blob + 53e63474210d3a0e7163235730f55a983a260757 (mode 644)
Binary files /dev/null and macros/exrc.ach.Z differ
blob - /dev/null
blob + 84a31e6ee40f5b48e61b91a51788f781db8d4bcb (mode 644)
Binary files /dev/null and macros/exrc.brp.Z differ
blob - /dev/null
blob + fadacbd37c94035455ee2a5a4baf9ce00543a438 (mode 644)
Binary files /dev/null and macros/fill.Z differ
blob - /dev/null
blob + 8967fe4f61815b1a1802ef2889e29a702f432142 (mode 644)
Binary files /dev/null and macros/fold.tar.Z differ
blob - /dev/null
blob + 8e5b22bbd32e1746ebee7a329b05fdfeaf370571 (mode 644)
Binary files /dev/null and macros/folding.Z differ
blob - /dev/null
blob + 12df2efb36f065f91654edefc54f65cb35d7b496 (mode 644)
Binary files /dev/null and macros/folding.d.Z differ
blob - /dev/null
blob + 3255e00447fdacc34626bc585ada75aaddf56e95 (mode 644)
Binary files /dev/null and macros/generals.2.Z differ
blob - /dev/null
blob + f86ce96ca87fff162709c22ad4feba54eb6837e7 (mode 644)
Binary files /dev/null and macros/generals.Z differ
blob - /dev/null
blob + e2c76afd8008d02228e2eb64c9260b7db1395b9b (mode 644)
Binary files /dev/null and macros/goodies.tar.Z differ
blob - /dev/null
blob + 5d2da72cfec9c159f1ddf46f4e54e8d9f6fb9999 (mode 644)
Binary files /dev/null and macros/hanoi.Z differ
blob - /dev/null
blob + 98314a3a2c1ff47e19ca891250498c9d2c064f42 (mode 644)
Binary files /dev/null and macros/ispell.Z differ
blob - /dev/null
blob + 6da8de2bce6632c7e34bf65cec6384e74f9ac882 (mode 644)
Binary files /dev/null and macros/jl.ex.Z differ
blob - /dev/null
blob + d7d361e2106694dbd60ee138c28f69c2562ae2ec (mode 644)
Binary files /dev/null and macros/latex.Z differ
blob - /dev/null
blob + 9addaf5196683039dd30261289ba7fadf9e9c6b8 (mode 644)
Binary files /dev/null and macros/latex2.Z differ
blob - /dev/null
blob + 978ced166d228e9d744b6d702ed11264c9dcd3aa (mode 644)
Binary files /dev/null and macros/mail.enc.Z differ
blob - /dev/null
blob + 5eb65a8cb3866837fa99d9c11df99cbb7e1483f5 (mode 644)
Binary files /dev/null and macros/man.Z differ
blob - /dev/null
blob + c56fb208e5438e34145958f1ea6a2c00457d1894 (mode 644)
Binary files /dev/null and macros/markring.Z differ
blob - /dev/null
blob + 45f7b9afa38f3ac8dab481fcb7965a4e889c8c69 (mode 644)
Binary files /dev/null and macros/maze.tar.Z differ
blob - /dev/null
blob + 0f748006b44e272667a73e2ee02d4f17a6f4b55d (mode 644)
Binary files /dev/null and macros/modula2.Z differ
blob - /dev/null
blob + d2ece17d55b08304fc3a02c8f7efee2ebc2a6e65 (mode 644)
Binary files /dev/null and macros/modula2.new.Z differ
blob - /dev/null
blob + 5f664b9c480ed5a1bd56232a27acd0f0dc007035 (mode 644)
Binary files /dev/null and macros/morse.Z differ
blob - /dev/null
blob + 2621e7db766c9c225f466198f011e4ef0184f23a (mode 644)
Binary files /dev/null and macros/pascal.Z differ
blob - /dev/null
blob + da8f9d6ff75c67bf798bc2714a507f8f64fdd159 (mode 644)
Binary files /dev/null and macros/perl.Z differ
blob - /dev/null
blob + 95aaea6319bb166d154fc22a5eb15a4e12c4b410 (mode 644)
--- /dev/null
+++ macros/rcs.Z
+ "@pФadLA8nܙ¡:k@
+&aؔI sgAm(C&
+7r15e9(evҀhf AS` #G CG
+ 43aܤ357<CUᄁSIǔ7wȔqӸ;&O *o&\aĉ\\sg7yq
+ qSNߥM 4vfFKtG3 (`
+7 tn D:ʄ0ߠc탽+q[@N1llqRe4vqTwweܭg
+pb>A-_w\dH%-UGǤuQ(n
\ No newline at end of file
blob - /dev/null
blob + 50684dbb41df89a26c848a8b601bd8ec482f9898 (mode 644)
--- /dev/null
+++ macros/ruler.Z
+ "@Ǭr' 8.9bJ 7.<i4lR
+Z:9
+2dyæN7-8\SF6iܔDcxcN yp'/A"F 2hQđ&TR*
+0b_1+CHc6 xc
\ No newline at end of file
blob - /dev/null
blob + 729ab31ac72851bacbe35a464c32773043fc334e (mode 644)
Binary files /dev/null and macros/srm.Z differ
blob - /dev/null
blob + 861c36b03679d23a259cef99269d7325d3c249dc (mode 644)
Binary files /dev/null and macros/turing.tar.Z differ
blob - /dev/null
blob + efc0603c91747e2b216ab2fe85d4f803a8330fe7 (mode 644)
Binary files /dev/null and macros/upcase.Z differ
blob - /dev/null
blob + a7ad2014f3a649d8169bf33f37c66d9f745a5bf4 (mode 644)
Binary files /dev/null and macros/vogel.tar.Z differ
blob - /dev/null
blob + bea12db1e12e07846725b554b6c3a2e6f2cbdc69 (mode 644)
Binary files /dev/null and macros/wordsearch.Z differ
blob - /dev/null
blob + aae27f5cf942f59b522bcd219c2cafb925e6dec8 (mode 644)
Binary files /dev/null and macros/wordsearch.d.Z differ
blob - /dev/null
blob + 1f51f2565b446044b97705bf7cc990a5db17a4c8 (mode 644)
Binary files /dev/null and macros/ws.Z differ
blob - /dev/null
blob + 2ed9a9d41aebf7cca2de645e28ef77eb2de22fb4 (mode 644)
--- /dev/null
+++ programs/Readme.vim
+README for version 1.27 of Vim: Vi IMitation.
+
+Vim is an almost compatible version of the UNIX editor vi. Only the 'Q'
+command is missing. Many new features have been added: multi level undo,
+command line history, filename completion, quoting, etc. See difference.doc.
+
+This editor is very useful for editing programs and other plain ASCII files.
+All commands are given with normal keyboard characters, so those who can type
+with ten fingers can work very fast. Function keys can be used for macros.
+
+Vim currently runs under Amiga DOS, MSDOS and UNIX. Porting to other systems
+should not be very difficult.
+
blob - /dev/null
blob + 2121f3d1f43aa04292ec6bc02ca21052dee2c078 (mode 644)
--- /dev/null
+++ programs/Readme.xvi
+Xvi is a portable multi-window version of `vi'. In spite of its name,
+there is, as yet, no X-Windows-specific version of it, but work is
+still in progress. Existing versions use text windows separated by
+horizontal status lines on character mode displays. The windows may
+represent different files being edited, or different views on to the
+same file.
+
+Unix, MS-DOS and QNX versions have now been in regular use by the
+authors, and many of our colleagues, for about three and a half years,
+and the editor's behaviour seems fairly satisfactory.
+
blob - /dev/null
blob + af84acc2ef5c6a16e327dc16142295d5f1420ab5 (mode 644)
Binary files /dev/null and programs/msdos/calvin21.zip differ
blob - /dev/null
blob + 9126b1e450ba2a7e663ba6092c89036777a5d42d (mode 644)
Binary files /dev/null and programs/msdos/vim127x.zip differ
blob - /dev/null
blob + b1e96f22d6f399965db08f2b7e3645b7e0658fb0 (mode 644)
Binary files /dev/null and programs/msdos/xvidoc.zip differ
blob - /dev/null
blob + 2b6667120c569bf209eaa84b449e39c4f07a7408 (mode 644)
Binary files /dev/null and programs/msdos/xviexe.zip differ
blob - /dev/null
blob + 4fd64e6f057f45e9f3283200222ddc16e63fd41d (mode 644)
Binary files /dev/null and programs/unix/bined.tar.Z differ
blob - /dev/null
blob + a53e825187fccc8cfaf33059b442f45ebd00ba83 (mode 644)
Binary files /dev/null and programs/unix/bvi.tar.Z differ
blob - /dev/null
blob + febc6feb59e7b52a1434fe5376863b83617523ab (mode 644)
Binary files /dev/null and programs/unix/reformat.tar.Z differ
blob - /dev/null
blob + 93f04ade1f6f70530161ee9d01d281896aeb191e (mode 644)
Binary files /dev/null and programs/unix/rvi.tar.Z differ
blob - /dev/null
blob + 741d5a85c27f2392422a4ea73239191b6b570c8d (mode 644)
Binary files /dev/null and programs/unix/vi-buffer.el.Z differ
blob - /dev/null
blob + d08f5347e239b2f72cb8f01ad5339695e1ec3afe (mode 644)
Binary files /dev/null and programs/unix/xvi.tar.Z differ
