commit 8d6e68fc21a02c9a133f2dbfe760939bf49729bf from: mischa date: Sun Jun 16 19:59:42 2024 UTC Commit archive commit - /dev/null commit + 8d6e68fc21a02c9a133f2dbfe760939bf49729bf blob - /dev/null blob + b2c3b4d648e988989bcac59b8967322b736c36bf (mode 644) --- /dev/null +++ HELP @@ -0,0 +1,162 @@ + + HELP ON USING THE MAIL INTERFACE AT VI/EX ARCHIVE alf.uib.no + ************************************************************ + + BEWARE: If you have anon. ftp capability, please use that instead of + this mailserver (see below). + + VI/EX Archive alf.uib.no, and its mirrors have the most complete, and + the biggest publically available archive containing VI/EX stuff. + + To access the mailer, just send a mail message to ruben@uib.no. + You have two ways of fetching files: + 1) Single file. + 2) Multiple files. + + + Single file request + ~~~~~~~~~~~~~~~~~~~ + In the Subject field in your header of your message you simply put + GET . + + 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 . + + 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 @@ -0,0 +1,298 @@ +# +# Index of archive: alf.uib.no (129.177.30.3) +# Filearea: /pub/vi +# Archive maintainer: Ove Ruben R Olsen ruben@uib.no +# Archive updated: Sat May 20 11:55:33 GMT 1995 +# Mirroring archives: utsun.s.u-tokyo.ac.jp (133.11.11.11) +# cs.uwp.edu (131.210.1.4) +# ftp.uu.net (192.48.96.9) +# monu6.cc.monash.edu.au (130.194.1.106) +# + +If one of the mirror-archives are closer to you, plase get the files +from there. + +There are 4 directories: + docs - Documentation on VI, also some comp.editors postings + macros - VI macros + comp.editors - Various materials posted to comp.editors + programs - VI's for various platforms (and programs). + + +UCB = University of California, Berkley. (Hometown of vi) +CED = Comp.editors discussion/article in NetNews. + +################################################################################ +DIRECTORY: pub/vi/ + +INDEX This file. +HELP Help file for the Emailserver. +POINTERS Pointers to other interesting stuff. (VI resemblence). +WHO A 'thank you' too all who have submitted to the archive. +comp.editors.ARC Comp.Editors FAQ VI/EX archivelist. +comp.editors.EDS Comp.Editors FAQ list of editors. +comp.editors.FAQ Comp.Editors FAQ. +comp.editors2 The other file posted to comp.editors once in a while. +comp.editors3 Standard reply for info. requests on C.E. + + +################################################################################ +DIRECTORY: pub/vi/docs + +8bit.Z CED: 8 bit clean implies what? +advocasy.Z Advocating VI by Martin Weitzel. +apwh.ms.Z VI Command & Function Reference. UCB-dist. +arrowkeys.Z Arrow keys in VI. +bed.tar.Z A frontend to VI for edtiting binary files. Version: 1.0 +beginers.Z VI beginers guide. +books.Z A short note on books on VI. +bugs.Z Bugs and explanation of those. +capitalize.Z Capitalizing first [a-z] letter in sentence in vi +card.tex.Z VI reference card in TeX. Found inside learn-vi.tar.Z +caseconv.Z Converting Proper case to Upper case in Vi. +casesr.Z Changing case during search and replace in VI. +chars.Z Appendix: character functions. UCB-dist. A Must. +chars.tex.Z A \LaTeX fyed version of vi.chars.Z. Maurizio Codogno. +ckv.Z Diary/Log editing and C-programming. +ckv2.Z RCS-maintaining and Shell programing. +course.Z A course on using VI. Paper. +course.tar.Z A course package on using VI. Paper. +crypt.Z Tips and macros on handling crypted files/mail. M. Wyle. +ctags.Z Various stuff about Ctags and VI. +e2.tar.Z A File history interface. A must. Version: 1.3 +editech.1.Z General techiques on editor implementation. +editech.2.Z Updating the screen in a buffer-gap editor. +editech.3.Z How to 'store' the file in memory. Buffer GAP method. +editech.4.Z Buffer management in the Poplog editor VED. +editech.5.Z Questions (and answers) about buffer-gap implementations. +editech.books.Z Information on writing text editors +elvis.Z Laitest ELVIS (1.5) doc - The VI clone that run on most OS. +ex.changes.Z EX changes from version to version. UCB-dist. +ex.fix.Z An Encore EX fix. +ex.reference.Z EX Reference Manual. UCB-dist. A Must. +ex.summary.Z EX Command Summary. UCB-dist. +formating.Z Textformating inside vi wiht or without external program. +globaldelete.Z :g/string/d in macro buffer !working +help.Z VI recerence card. Found inside learn-vi.tar.Z +innforing.Z A NORWEGIAN introduction to VI. Version 1.3-160. +intro.Z Introduction on Display Editing with VI. UCB-dist. A Must. +intro.ps.Z vi.intro in PostScript format. UCB-dist. +jl.ex.ref.Z Another reference for VI. +keybind.Z Tips on binding keys (map/map!). CED -posting. +keymapings.Z About key-mappings. +keys.Z What key's to map in VI. Table. Followed by a CED. +love.Z A colletions of "Why do you love vi ?" from comp.editors. +lvi.tar.Z The Learners Introduction to VI. Interactive. Bo Thide. +macroDoc.tar.Z Two docs describing macros in VI. Sample exrc file incl. +macros.Z Macros, Abbrevitations, and Buffers. +macrotips.Z Various macrotips. +man.tut.Z VI manual-page with a tutor. +mks.ant.Z Tips on macros in the MKS version of VI. Anthony C Howe. +motd.tar.Z Global /etc/motd file editor. +move.Z Hints file: Move Text from One File to Another. Dr. L. Leff +multfile.Z A doc on how to work with multiple files in VI. +mvi.c.Z Direcotry utility using VI. +nvi.tar.Z Novice VI. Bo Thide. +online-200.tar.Z VI ON-LINE HELP with 'windows for vi'. Version 2.00 +passwd.Z A script for "secure" editing of /etc/passwd. +passwd.fix.Z A fix to vi.passwd.fix.Z +patch.Z Patch to fix a "security" hole in VI. +quick.Z VI Quick reference card. +rcut.tar.Z Rectangular cut and paste for VI. Robert Colon. Good. +ref.Z UNIX VI quick reference card. +refchrt.Z VI reference chart. +reference.Z VI reference. Version 8. Maarten Litmaath. A Must. +reference.ms.Z VI reference for typesetters. +sections.Z Sections in VI. +shell-101.BetaA.Z Conversion table between different shells. +sigint.fix.Z A src fix for VI dealing with 'sigint'. +song.Z A song about VI. +ss.qrf.Z Super Short quick reference card. Fits on a 80x24 screen. +summary.Z VI / EX Quick reference. UCB-dist. +tabd.Z Tabs and Blanks - Infavor of 8 column tabs. John E. Davis +tagStack.Z Patch for vaxen to make tag stack avail. Fixes for sun. +tags.Z A paper on a tag-technique. Using tags like macros. +terse.help.Z Extremely terse VI reference notes. Michael A. Crowley +tips.Z Beginer's tips on VI. +tutor.Z The tutor-file from vi.tutor.tar.Z (tutor.vi). +tutor.tar.Z An interactive tutor for VI. (Ver: 1.3) Beginner's choice. +tutor.tex.Z A exellent documet to use with vi.tutor.Z. Beginner's choice +ucb.tar.Z* The whole UCB-dist package. +vi.1.Z VI formated help manual. BEWARE: Not a "real" manual. +vifs.tar.Z Edit-file stack. CTAGS and VI effectively. Seigo Fujii. CED +vilearn.tar.Z A interactive VI tutorial in 5 movements. +vms.Z Information about VI for the VMS environment (DEC-VAX). + + +* DO *_N_O_T_* try to fetch this file via the Email interface. Most UUCP + mailers do NOT like files with more than 100000 bytes. A uuencoded version + of this file is 2833 lines long and 175445 bytes big. The contenst of this + tar archive is spread around as several files. I will under NO circumstances + ever implement a mail spliting in the mailserver. I have other more usefull + things to do. + + +Beginner's in VI should fetch the following files +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +The following is a 'must' for starters: +intro.Z Introduction on Display Editing with VI. UCB-dist. A Must. +reference.Z VI reference. Version 8. Maarten Litmaath. A Must. +beginers.Z VI beginers guide. +tutor.Z The tutor-file from vi.tutor.tar.Z (tutor.vi). +card.tex.Z VI reference card in TeX. Found inside learn-vi.tar.Z +tutor.Z The tutor-file from vi.tutor.tar.Z (tutor.vi). + + + +################################################################################ +DIRECTORY: pub/vi/macros + + +README - A readmefile about the macros in this archive. +ball.tar.Z - Bouncing ball macro. Gadepalli, Balu, Subramanian. +blocks - Block- delte, move and copy. Sep 24 1991. Geoff Clare. +blocks.d.Z - Explanation of the blocks-macros. Sep 24 1991. +c.template.Z - Vi C-mode. Mitchell Wyle. +case - Convert case on word/line. * Bryan Ewbank. +case.word - Another word-case converter... Bryan Ewbank. +case.word2 - An improved case.word. * Jon Eiseman. +cases.d.Z - CED about vi and caseconversions. +caseword - Convert case on word. Eelco van Asperen. +center - Center text, spell check. Dave Beyerl. +cil.tc - Comment, Invert, Lint. Tom Christiansen. +cmacros - Small and quick C-macros. CED. +commentC.tar.Z - Very good way to do C-comments. Rob Hutten. +complete - Word completions using CTRL-Keys. E. Bowles. +complete.ext - Some extensions to 'complete' +complete.new - New version of complete. +cvi.Z - C Syntax Sensitive editing. Bo Thide. +emacs.style - Emacs style editing. Steve Kinzler. +evi.tar.Z - Full Blown Emacs emulator. Bo Thide. +execute - Easy way to execute exsternal commands. Stephen Reihm. +exrc.ach - "The Super .exrc File" compiled by Anthony C Howe. +exrc.brp - A nice exrc file from Bill "Rock" Petro. +fill - An easy way to fill a paragraph. Seigo Fujii. +fold.tar.Z - A folding package E. Bowles.. +folding - The macro from folding.d.Z. +folding.d.Z - CED about "fold-editing" with vi. +generals - General, text, mail, C, Modula-2. Compiled by M. Lamoureux +generals.2 - EXRC and Pascal. Bradford L Knowles. +goodies.tar.Z - Find prev word, emacs-mode, C-mode and others. M. Neitzel. +hanoi - VI solves the infamous 'Towers of hanoi'. Greg McFarlane. +ispell - Spellcheckig for VI with ispell. Philip Kizer. +jl.ex - Some 'beginer' macros. Joel Loo Peing Ling. +latex - Latex mode. (Wery few, but promising) Mitchell Wyle. +latex2 - Latex mode. Oeyvind Flaam. +mail.enc.Z - Working with encrypted mail. Good. Mitchell Wyle. +man - Manpage lookup. Untested. +markring - Marking places in the text the easy way. Daniel Smith. +maze.tar.Z - Maze solving with vi. Greg McFarlane. +modula2 - Modula-2 macro package. Mitchell Wyle. +modula2.new - Modula-2 macro package. Roland Bickel. +morse - Write morsekode. Hugh McGuinness. +mymorse - Exchangement to 'morse'. No map!ings of lowercase. +pascal - Pascal mode. {\O}yvind Brusevold. +perl - Perl mode. Kenneth C Rich. +rcs - RCS vi macros. Phil Male. +ruler - Rulermacro. Bill Petro. +srm - Search and Replace macro. Very HEAVY stuff.. :-) D Wallach +turing.tar.Z - A turing machine with vi. Dave Hitz. +upcase - Turn your last typed word in to uppercase letters. L. Quin. +vogel.tar.Z - The Karl Vogel collection. Cmode. Logfile. SHmode. RSChelp. +wordsearch - Macro from wordsearch.d.Z. Elliott C Winslow. +wordsearch.d.Z - CED about searching for word under cursor. +ws - Word Star emulator. Version 0.00. Ove Ruben R Olsen. + +* I have not got this to work. + + + +################################################################################ +DIRECTORY: /pub/vi/comp.editors + +8bit.Z CED: 8 bit clean implies what? +append.Z Appending to external file with vi. +blankline.Z Removing / inserting blank lines in vi +blockdel.Z Deleting a block of text +blocks.Z Macros for block copy/move +buffer.Z View Content of Buffer +buffera.Z Clearing anon vi buffers (in Elvis) using :e command. +ced.tips.1.Z Comp.Editors tips collection. October 91 issue. +ced.tips.2.Z Comp.Editors tips collection. November 91 issue. +ced.tips.3.Z Comp.Editors tips collection. December 91 issue. +ced.tips.4.Z Comp.Editors tips collection. January 92 issue. +ced.tips.5.Z Comp.Editors tips collection. February 92 issue. +ced.tips.6.Z Comp.Editors tips collection. March 92 issue. +ced.tips.7.Z Comp.Editors tips collection. April 92 issue. +ced.tips.Inx.Z Comp.Editors tips collections INDEX file. +cmdline.Z EX-mode command line editing in vi +cols.Z Switching cols in VI +columedit.Z Using vi to edit columns +counter.Z Counter in VI +countwords.Z How to count words +crlf.Z How do I remove new-lines [CR,LF] in vi ? +cshline.Z A csh command line editor using vi. Ian Phillipps. +ctrl.Z How to enter CTRL-sequences in VI. Escape seq. also. +currfn.Z Grab current Filename in VI? +cutpaste.Z Cut and Paste with VI. +demyst.Z Demystifying vi one step further.. A CED discussion. +executing.Z About !shell, piping and unix commands inside VI. +history.Z Various "historical" aspects of VI. +insert.Z About inserting text. +interface.Z Interfaces to vi. +linetolong.Z The infamous 'Line too Long' - What can be done. No answer. +macrolimits.Z Macro limitation +mapping.Z Various about mappings. +mapspace.Z How to map . +maptab.Z How to map . +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 to . +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 @@ -0,0 +1,30 @@ +This repo contains the information in the vi archive and FAQ at: + + ftp://ftp.uib.no/pub/vi/ + +as of March 2017. + +The archive, lovingly curated by + + Ove Ruben R Olsen + +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 @@ -0,0 +1,28 @@ + +The folowing persons have contributed to this archive, and I and +the NET owe them a thanks: + +Larry V. Wirden (lwv27@CAS.Bitnet) for more than 60 files ! +Erik E. Bowles (bowles@is.s.u-tokyo.ac.jp) for a macro and MIRRORING ALF ! +Hugh McGuinness (hughm@tplrd.tpl.oz.au) for a macro. +Chet A. Creider (creider@taptet.sscl.uwo.ca) for a vi tutor in LaTeX. +Hans Mulder (hansm@cs.kun.nl) for vi.bined.tar.Z +Geoff Clare (gwc@root.co.uk) for the blocks macros. +Contr Karl Vogel (vogel@c17igpb.wafb.af.mil) for vi.ckv?.Z +Dave Datta (datta@cs.uwp.edu) for MIRRORING ALF ! +Bo Thide (bt@irfu.se) for cvi.Z +Mitch Wyle () for vi.crypt.Z +Bill "Rock" Petro (Bill.Petro@Eng.Sun.Com) for exrc.brp. +Alex Martelli (martelli@cadlab.sublink.org) for vi.xvi.tar.Z +Gary Smith (uunet!ddi1!lrark!glsrk!gars) for GEnie MIRRORING. +Roland Bickel (rmbicke@cs.vu.nl) for modula2.new +Steve Balogh (steve@monash.edu.au) for MIRRORING ALF ! +Maurizio Codogno (mau@bilbo.CSELT.STET.IT) for vi.chars.tex.Z +Maarten Litmaath (maart@nat.vu.nl) for vi.reference.Z +. +. +. + +And others that I unfortunatly have forgot... If you miss your name, +please tell me so... + blob - /dev/null blob + 33470fda4dbd27a06c2348239abe1b3354c6819d (mode 644) --- /dev/null +++ comp.editors/8bit @@ -0,0 +1,752 @@ +From: davis@pacific.mps.ohio-state.edu ("John E. Davis") +Subject: 8 bit clean implies what? +Reply-To: davis@pacific.mps.ohio-state.edu (John E. Davis) +Date: Sat, 6 Feb 1993 18:22:29 GMT +Lines: 46 + +Hi, + +I have a few questions regarding the meaning of 8 bit clean editors. + + +As I understand it, an editor which is 8 bit clean can display ALL 256 +characters on the output device. That is, the character should not be mapped +to a displayable representation (i.e., ascii char 1 to two character sequence +^A). So for example, if character 235 corresponds to the greek letter alpha +on the output device, an alpha should appear when char 235 is sent. In +addition, the editor should be able to take ANY 8 bit character form the input +device and display it. That is, if the input device is capable of sending the +char 235 (alpha), then the char should be deisplayed as above. Is this +correct? + +On my PC, the char 255 do not display anything on the screen (just a space). +255 is also -1 when converted to signed char and usually denoted end of file +or something special like that. Is it just a coincidence that 255 displays +nothing on my PC or is this a general feature? Should I make any assumptions +regarding 255? I would like to reserve it for my own purposes. + +Finally, are characters with the hi bit set (>= 128) ever involved in keymaps? +This might seem like a silly question but for my purposes, it is the most +important question. I tend to think of keymaps as involving only 7 bit chars, +e.g., escape map. But is any known case of a keymap where the prefix character +has the high bit set? + +In case you are wondering, I am working on an editor (JED). Recently, I +released version 0.80 which I thought to be 8 bit clean, but in retrospect, it +is not. I hear people say ``Just treat ALL characters the same!''. However, I +am concerned with memory usage on PCs and I would like to cut corners wherever +I can. Berfore I release the next version (0.81), I want to make SURE that I +get the 8 bit thing correct. + +I appreciate any comments on the subject. Thank You. + + + +-- + _____________ +#___/John E. Davis\_________________________________________________________ +# +# internet: davis@amy.tch.harvard.edu +# bitnet: davis@ohstpy +# office: 617-735-6746 +# + + +From: michael@chpc.utexas.edu (Michael Lemke) +Subject: Re: 8 bit clean implies what? +Organization: The University of Texas System - CHPC +Date: Sat, 6 Feb 93 20:38:11 GMT +Lines: 38 + +In article davis@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@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@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@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@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 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 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 @@ -0,0 +1,81 @@ +From alm@netcom.com (Andrew Moore) +Subject: Appending to external file with vi? +Date: 8 Jul 92 19:49:43 GMT +Article-I.D.: netcom.#77lg=q.alm + +I use the vi (ex?) command format: + + :'x,.w file + +to write a section of text to an external file (file). +But I don't know good way to append to an existing file. +The best I can think of is: + + !'xtee -a file + +where ! filters from the current position to 'x through tee. +Any ideas are welcomed. Thank you. +-Andrew Moore + + +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 @@ -0,0 +1,278 @@ +From akf@awful.august.com (Andrew Fullford) +Subject: Re: Removing blank lines in vi +Date: Mon, 31 May 1993 04:25:36 GMT + +>>>does anyone know how to remove blank lines from a file using vi?. + +>Using +> :g/^$/d + +>should do the job. + +This is splitting hairs, I know, but the original poster said "blank" +lines: + + :g/^[ ^I]*$/d + +(that's "space tab"). + + +From hansm@wsinti06.info.win.tue.nl (Hans Mulder) +Subject: Re: ddn.n.n.n.n. (oops, one too many) u (was: Removing blank lines in vi) +Date: 1 Jun 1993 21:21:27 +0200 + +In <1ufv9eINNb1o@uwm.edu> markh@csd4.csd.uwm.edu (Mark) writes: +>Maybe I wasn't totaly clear, in which case I'm sorry. The question is, how +>do you automate this in vi: n.n.n.n.n. (until n fails)? + +If you like to live dangerously, type: + +:map q n.qm + +This makes typing q do what you asked (n.n.n.n.n. until n fails). +And yes, typing u afterwards will ondo the last one. + +I usually :w before I do this, and :unmap q when I'm done, just in case. + +You might like to know about :set nowrapscan, which stops searches at +both ends of the buffer, which can be useful if you do things like this. + +The sole purpose of the m at the end of the :map is to stop vi from +saying "No tail recursion". I don't understand why tail recursion +is not allowed, while general recursion is. + +HansM + + +From dattier@genesis.MCS.COM (DWT) +Subject: Re: Removing blank lines in vi +Date: 27 May 1993 14:14:18 -0500 +Reply-To: dattier@genesis.mcs.com (DWT) + +dberg@informix.com (David I. Berg) wrote in 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 /* 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 @@ -0,0 +1,63 @@ +From jafo@miranda.accum.com (Sean Reifschneider) +Subject: Re: vi - deleting a block of text +Date: Sat, 29 May 1993 00:50:39 GMT + +In article <1993May28.033037.18425@trl.oz.au> soh@tmp_ip_003.trl.OZ.AU (Soh Kam Hung) writes: +>mimit@benji.Eng.Sun.COM (Mimi Tam) writes: +>>What is the easiest way in vi to delete a block of text without knowing +>>the line numbers and without knowing how many lines are in the block? +> +>Note: 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: 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 to store the cursor position in mark . + +2. Move the cursor to the end of the block. Type: + + d' - delete to the line containing the mark. +or d` - 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 @@ -0,0 +1,62 @@ +From beaumont@CompSci.Bristol.AC.UK (Tony Beaumont) +Subject: vi macros for block copy/move +Date: 4 Jul 92 13:10:51 GMT + +I am using vi and I have four macros defined in my .exrc for block +operations on text: + +\C and \c copy a block of text (from between marks a and b) to before +or after the current cursor position. +\M and \m move a block of text (from between marks a and b) to before +or after the current cursor position. + +The lines in my .exrc to define these macros are as follows... + +map \C mz'b"zy'a'z"zP +map \c mz'b"zy'a'z"zp +map \M mz'b"zd'a'z"zP +map \m mz'b"zd'a'z"zp + + +My problem is this, whever I do \c or \C I get a beep from my terminal. This +does not happen when I do \M or \m. The beeping seems to come after the text +is put into the z buffer and before moving back to the z mark to put the text. + +I do not get the beep if I type the command sequences for \c and \C by hand. + +Anyone tell me why I get a beep and how I can get rid of it. +(please reply by email because I don't read this newsgroup often. I'll +post any solutions that work back to the newsgroup) + +-Tony Beaumont + +======================================================== +email: beaumont@uk.ac.bristol.compsci +snail: Tony Beaumont, + Advanced Computing Research Center, + University of Bristol, + Bristol, BS8 1TR, + UK +======================================================== + + +From brandy@tramp.Colorado.EDU (BRANDAUER CARL M) +Subject: Re: vi macros for block copy/move +Date: Tue, 7 Jul 1992 17:27:47 GMT + +Using macros to do block copying/moving seems overly complicated since +there are ex/ed commands designed for the purpose. From my SVR3 manual: + + (.,.)ma + +will move the addressed block after the line addressed by a, while + + (.,.)ta + +will duplicate the addressed block after the ine addressed by a. Both +work in vi even though ex uses different command names. + +Note that with these commands you are no longer restricted to using marks +for selecting the block, although they work just fine. + +Cheers - Carl blob - /dev/null blob + 1495f19d4c05d66f1c25f0e383174d6e0d173a07 (mode 644) --- /dev/null +++ comp.editors/buffer @@ -0,0 +1,83 @@ +From cn@Materna.DE (Carsten Neumann) +Subject: Re: View Content of Buffer +Date: 1 Jul 93 12:57:36 GMT + +In <1993Jun30.075639.5512@alf.uib.no> chun@eik.ii.uib.no (Chunming Rong) writes: + +> Does anyone know how to view the content of the buffers within VI? +> Emacs has such function. + +What's wrong with + "ap +for printing buffer a at cursor location and + u +for clearing this lines? + +BTW: Please cut your .sig! +Carsten +-- +Carsten Neumann cn@Materna.de (+49 231) 5599-196 (work) +Schwerter Str. 215, DW-4600 Dortmund 41, (+49 231) 448341 (home) + + +From mac@bnr.ca (Michael Campbell) +Subject: Re: View Content of Buffer [VIM can do this] +Date: 2 Jul 1993 16:56:59 GMT + +I have heard a lot of praise for VIM in this group (and others). I +downloaded a copy myself a few weeks ago, to my DOS/Windows box, and +gave it a whirl. I almost immediately removed it from my machine when +I discovered that it *insists* on displaying my .exrc :map commands on +the terminal prior to bringing up the file I have asked it to edit. +The documentation suggests that this is the way it is supposed to act +under DOS. Strangely enough, it doesn't do this under Unix (also +tried the Unix variant of the same version). + +So the question is (if you haven't guessed by now!), is there any way +to stop VIM from displaying the :map commands when run under DOS? +This is so annoying that I returned to Elvis, which is very good. +Thanks in advance for any help. + +======================================================================== +Michael Campbell BNR Inc. Richardson, Tx. +214-684-5595 (ESN 444) Dept 2Q35 email: mac@bnr.ca +======================================================================== +"A baby is a bundle of needs that initiates a 20 year parental emergency" +-Gail Sheehy + + +From darkstar@bach.udel.edu (The Sleepless Wonder) +Subject: Re: View Content of Buffer [VIM can do this] +Date: Fri, 2 Jul 1993 20:31:35 GMT + +In article <211pcr$1bb@crchh327.bnr.ca> mac@bnr.ca (Michael Campbell) writes: +>I have heard a lot of praise for VIM in this group (and others). I +>downloaded a copy myself a few weeks ago, to my DOS/Windows box, and +>gave it a whirl. I almost immediately removed it from my machine when +>I discovered that it *insists* on displaying my .exrc :map commands on +>the terminal prior to bringing up the file I have asked it to edit. +>The documentation suggests that this is the way it is supposed to act +>under DOS. Strangely enough, it doesn't do this under Unix (also +>tried the Unix variant of the same version). +> +>So the question is (if you haven't guessed by now!), is there any way +>to stop VIM from displaying the :map commands when run under DOS? +>This is so annoying that I returned to Elvis, which is very good. +>Thanks in advance for any help. + +Well, believe it or not, there is a way around it. (I should probably +cross-post this to alt.hackers 8) + +Rename _vilerc to something like vile.rc (sounds like a good DOS name). +Then set your exinit environment variable to this: set exinit=so vim.rc + +What happens is that vim doesn't find the default rc file so thus +defaults to looking at the env variable for instructions. The +instructions say to source file. When a file is sourced, it doesn't +display the key mappings... + +Now, to make two comments. VIM is a great editor/vi clone, with one +exception. VIM has to edit the file in memory. No problem on +systems with flat memory models, but on DOS boxes, you can't edit large +files (approximately anything larger then 700k on my system). I think +that the \ No newline at end of file blob - /dev/null blob + 7483e6d32026b5cc428c73c3f503e9ce7bb36c00 (mode 644) --- /dev/null +++ comp.editors/buffera @@ -0,0 +1,80 @@ +From ray@hebron.connected.com (Ray Berry) +From: ray@hebron.connected.com (Ray Berry) +Newsgroups: comp.editors +Subject: clearing anon vi buffers +Date: 16 Dec 1993 11:01:45 -0800 +Organization: Ascendant Systems +Lines: 10 + + I happily encountered 'elvis' the other day which seems a fairly +high quality effort at a vi clone. I was a bit surprised however +at the fact that it clears the anon buffers when you change files +via :e etc. From a philosophical point of view I can see how this +behavior might be defended. But alas, transporting text between files +with the default cut buffer is a habit I had fallen into. + I'm wondering if there is any formal rule on this point. +I appeal to the vi mavens here for a clarification. +-- +ray berry kb7ht rjberry@eskimo.com ray@connected.com 73407.3152@compuserve.com + +From creider@taptet.sscl.uwo.ca (Chet Creider) +From: creider@taptet.sscl.uwo.ca (Chet Creider) +Newsgroups: comp.editors +Subject: Re: clearing anon vi buffers +Date: Thu, 16 Dec 1993 21:22:53 GMT +Organization: University of Western Ontario, London +Lines: 15 + +In article ray@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 + + +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@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 @@ -0,0 +1,1033 @@ +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' +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'. 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"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/"\"/''/ + +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 + + 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 (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 +|> +|> 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@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@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 @@ -0,0 +1,674 @@ +From kirkenda@eecs.cs.pdx.edu (Steve Kirkendall) +Subject: Quoting in ex/vi -- more info +Date: 12 Nov 91 01:15:09 GMT +Organization: Portland State University, Portland, OR +Status: O + +The first results are in on my question about character quoting in ex/vi. +The table below shows what I've learned from e-mail, and a few tests. +Please check it out, and let me know of any errors or omissions. + + ex vi .exrc characters to quoted +----+----+------+-------------------------------------------------------- + \ \ ^V The | command separator + \ ^V n.a. Special control characters on any command line + ^V ^V^V ^V Whitespace in a :map or :unmap command + \ \ \ Whitespace in a :set command + \ \ \ Meta-characters in a regexp or substitution text + \ \ \ The %, #, and ! characters in a shell escape/filename + + The "ex" column refers to command lines that are interactively typed + into ex, or for ex macros executed via ":@x". + + The "vi" column refers to ex command lines that are interactively typed + using vi's ":" command. It also works for vi macros/maps which use ":". + Please note that when you're defining the macro, though, you'll need to + quote any ^Vs to delay their effect until the macro is applied. Also, + to quote a whitespace character in a :map command, you need to actually + insert a ^V into the command line, which is done by hitting ^V twice. + + The ".exrc" column refers to commands in the .exrc file, or a file + which is executed via the ":so" command, or for the value of EXINIT. + +The quoting character for special control characters is different, but +this is probably due to the serial line discipline, and not so much +ex/vi itself. This also explains why ^V must be typed twice in vi but +only once in ex, to quote whitespace in a :map. Bearing this in mind, +the quoting character is consistent in all contexts except when the +'|' command separator is to be quoted in .exrc files. +------------------------------------------------------------------------------- +Steve Kirkendall kirkenda@cs.pdx.edu Grad student at Portland State U. + + +From abed@saturn.wustl.edu (Abed M. Hammoud) +Newsgroups: comp.editors +Subject: Vi and Tags file...(please help). +Date: 23 Nov 91 18:36:18 GMT +Organization: Washington University, ESSRL +Status: O + + + hello, I have been a very..very..dedicated vi user for a long +time now. I was always wondering about what people meant by tag files (I +program in C). I looked up the manuals we have in the lab and I could not +find something that was enough for me to understand what is a tag file +and how to use tags. I do a lot of programming...I have a big library +of functions that I usually call from within my programs...so what can +tags do for me....Please if any body can help me understand this I +would be very thankful. + +PS: Please no flames + +Thanks a million, ++-------------------------------------------------+-----------------------+ +|Abed M. Hammoud (KB0INX) | abed@saturn.wustl.edu | +|Washington University. | Office: | +|Electronic Systems & Signals Research Laboratory.| -Voice:(314) 935-7547 | +|Department of Electrical/Biomedical Engineering. | -FAX: (314) 935-4842 | +|Campus Box 1161, One Brookings Drive. | | +|St. Louis, MO , 63130 USA | | ++-------------------------------------------------+-----------------------+ + + +From kev@sol.acs.unt.edu (Mullet Kevin Wright) +Subject: piping in an ex keymap +Date: 23 Nov 91 19:34:38 GMT +Organization: University of North Texas +Status: O + +Recently, I posted a request for a way to do a pipe in an ex keymap. + +My post got garbled becuase I left the actual control characters from my +.exrc in and they, and everything east of them, got dropped in my post. + +A few intuitive folks knew what I meant anyway and gave me this really +nice solution (that I wasn't able to find in my O'Reilly & Associates +_Learning the vi Editor_ book. + +To place a | in an ex shell command, do a ^V^V| to put a literal ^V in front +of it. One ^V will just leave you with a |, you need an actual ^V| in the +text. + +Thanks to Steve Kirkendall and Hans Mulder for their insight. I'm writing +this in the inside of my O'Reilly book now. :) + +-Kevin Mullet + University of North Texas + + +From soh@andromeda.trl.OZ.AU (Kam Hung Soh) +Subject: EX / VI delete up-to and including +Summary: Addressing lines in vi and ex +Keywords: vi, ex +Date: 24 Nov 91 02:53:20 GMT +Organization: Telecom Research Labs, Melbourne, Australia +Status: O + +I use vi, and I frequently work with logical blocks using ``/'' or +``?'' to find the end or beginning of the block. For example, here is +a LaTeX construct: + +\begin{environment} + \begin{environment2} + sfdasfda + sfdafasd + asfdasfdfdas + \end{environment2} +\end{environment} + +If I want to delete the inner environment, I usually type: + +d/^ \\/ or d?^ \\? + +Unfortunately, this leaves the closing symbols behind, i.e: + +\begin{environment} + \end{environment2} +\end{environment} + +I noticed that the whole inner environment is deleted if I typed: + +d/^ \\/+0 or d?^ \\?+0 + +The ``+0'' after the pattern match makes vi think the line containing +the pattern is included in the text to be deleted. The SunOS 4.0.3 +manual on vi make no mention of this. As far as addressing lines is +concerned, what does the trailing ``+0'' mean to vi? + +(On a related matter, this operation seems to be equivalent to typing +the following in ex: :.,/^ \\/d and ?^ \\?,.d) + +The system I am using: SparcStation 1+, SunOS 4.1.1 + +Regards, + +--- +Soh, Kam Hung | h.soh@trl.oz.au | Telecom Research Laboratories, + | +61 3 253 6638 | POB 249 Clayton, Victoria 3168, Australia + + +From hansm@cs.kun.nl (Hans Mulder) +Subject: Re: EX / VI delete up-to and including +Keywords: vi, ex +Date: 25 Nov 91 14:07:11 GMT +Sender: news@sci.kun.nl (NUnet News Owner) +Organization: University of Nijmegen, The Netherlands +Status: O + +In <1991Nov24.025320.16271@trl.oz.au> soh@andromeda.trl.OZ.AU (Kam Hung Soh) writes: + +>I use vi, and I frequently work with logical blocks using ``/'' or +>``?'' to find the end or beginning of the block. For example, here is +>a LaTeX construct: + +>\begin{environment} +> \begin{environment2} +> sfdasfda +> sfdafasd +> asfdasfdfdas +> \end{environment2} +>\end{environment} + +>If I want to delete the inner environment, I usually type: + +>d/^ \\/ or d?^ \\? + +>Unfortunately, this leaves the closing symbols behind, i.e: + +>\begin{environment} +> \end{environment2} +>\end{environment} + +>I noticed that the whole inner environment is deleted if I typed: + +>d/^ \\/+0 or d?^ \\?+0 + +>The ``+0'' after the pattern match makes vi think the line containing +>the pattern is included in the text to be deleted. The SunOS 4.0.3 +>manual on vi make no mention of this. As far as addressing lines is +>concerned, what does the trailing ``+0'' mean to vi? + +Vi distinguishes "line" moves and "character" moves. If you apply the 'd' +operator to a line move, vi deletes the starting line, the target line and +all intervening lines. If you apply the 'd' operator to a character move +that ends on a different line, the parts of the starting and target line not +moved over are not deleted. The '/' operator usually produces character +moves, but the "+0" suffix makes it a line move. + +You can replace the "0" by an other line count, e.g. d/foo/+3 deletes line +up to and including the third line following the next occurrence of "foo"; +and + +d/^\\/-1 + +does what Kam Hung Soh wants with fewer keystrokes. Actually, he can save +one more keystroke: the '1' is optional, so + +d/^\\/- + +would also work. FWIW the '+' is also optional. +And you can type several of these offsets, e.g. + +d/foo/++ + +is equivalent to + +d/foo/+2 + +Finally, there is the possibility to tack on another search: + +d/foo/;/bar/ + +deletes up to (but not including) the first occurrence of "bar" after the next +occurrence of "foo". + +Oh, and all trailing delimiters are optional. + +>(On a related matter, this operation seems to be equivalent to typing +>the following in ex: :.,/^ \\/d and ?^ \\?,.d) + +They are exactly equivalent if you :set nowrapscan. Under wrapscan, there +are situations where :.,/foo/d would reply "First address exceeds second", +while d/foo/0 would merrily delete a large part of your buffer. + +-- +Hope this helps, + +Hans Mulder hansm@cs.kun.nl + + +From mrd@ecs.soton.ac.uk (Mark Dobie) +Subject: Re: Vi and Tags file...(please help). +Date: 25 Nov 91 09:52:58 GMT +Sender: news@ecs.soton.ac.uk +Status: O + +In <1991Nov23.183618.21929@wuecl.wustl.edu> abed@saturn.wustl.edu (Abed M. Hammoud) writes: + +> hello, I have been a very..very..dedicated vi user for a long +>time now. I was always wondering about what people meant by tag files (I +>program in C). I looked up the manuals we have in the lab and I could not +>find something that was enough for me to understand what is a tag file +>and how to use tags. + +I used vi for a few years before I found out about tags. Tags is one +of the features that sets vi apart from a lot of other editors. + +> I do a lot of programming...I have a big library +>of functions that I usually call from within my programs...so what can +>tags do for me....Please if any body can help me understand this I +>would be very thankful. + +Here is how I use them. You need to run "ctags" to generate a tags file +for vi to use. I usually have a target in my makefile and type "make +ctags" occaisionally to keep it up to date. The ctags command (in the +makefile) looks like, + + ctags *.c *.h libsrc/*.c libsrc/*.h + +This generates a file called tags with references to all the functions +in the program and library source. + +Now in vi, you can place the cursor at the start of a function name and +press ctrl-]. This will take you to the function definition (even in +another directory). You can read it or edit it and then you press +ctrl-^ to return to where you were. That's the simplest way to use +tags. + +Any more advanced users out there who might have built a hypertext +system :-) + Mark. + + +From hansm@cs.kun.nl (Hans Mulder) +Newsgroups: comp.editors +Subject: Re: Vi and Tags file...(please help). +Keywords: tagstack, push, pop +Date: 26 Nov 91 16:29:09 GMT +Organization: University of Nijmegen, The Netherlands +Status: O + +In <1991Nov26.135248.6911@cc.ic.ac.uk> cyber@sig.ee.ic.ac.uk (Nick Sales) writes: +>There is also a ":pop" command, which, not unreasonably, pops you up one +>tag, so returning you to your previous pre-push position. + +In this version of vi (the one that comes with SunOS 4.1.1, :version says +Version SVR3.1) control-T is bound to :pop. + +>There are some (undocumented at my site) options to do with the tagstack +>too: taglength/tl (how long it is), and tagstack/tgstck (?). + +Tagstack is a Boolean option, :set notagstack disables the :pop command +(why would anybody want to do that?). There is also a "tags" option, +specifying the list of files to be searched for tag definitions. + +>BTW, I also found option "window/wi" in there: anyone know what it does? + +It defines the number of lines drawn initially when you jump to a different +part of the buffer. More lines are drawn if you move around locally. +Useful when editing at low baud rates. On some versions of vi you can put +in your .exrc (for example) + +:set w300=5 w1200=11 + +This :sets the window option to 5 when working on 300 baud (or lower), +to 11 when using 1200 baud and the default (screen height-1) when using +a higher line speed. + +-- +Hope this helps, + +Hans Mulder hansm@cs.kun.nl + + +From gwc@root.co.uk (Geoff Clare) +Newsgroups: comp.unix.misc,comp.editors +Subject: What does this do? (was Re: Vi internal design doc. needed) +Date: 26 Nov 91 14:16:06 GMT +Organization: UniSoft Ltd., London, England +Status: O + +In <8460@autodesk.COM> dansmith@Autodesk.COM (Daniel Smith) writes: + +> quick! What does this do? + +>map ]/ lbywo/^[p"xdd@x + +There's no quick answer, because the behaviour depends on the current +cursor position and, if autoindent is set, on whether the current line +is indented and how far. + +The following analysis is all done from memory of the behaviour of the +vi commands used, not from trying out the macro, so please accept my +apologies for any inaccuracies. Note that the phrase "beginning of line" +refers to the first non-white-space character on the line. + +1. If the cursor is not on the last line of the file and not at the + end of a line, and either the line is not indented or autoindent is + not set, then it searches for the first occurrence of the word under + the cursor plus any white space which follows it, starting the search + from the beginning of the next line. + +2. If the cursor is on the last line of the file, then it behaves as in + (1) except that the search starts at the beginning of the current line. + +3. If the cursor is at the end of a line, then it beeps and does nothing. + +4. If autoindent is set and the current line is indented: + + 4a. If the indent extends beyond the first tabstop, and tab is not + mapped, then it beeps and moves the cursor to the start of the + next line. + + 4b. If the indent does not extend beyond the first tabstop, and + the number of spaces of indent does not exceed the number of + characters on the next line (not including any leading white + space), then it behaves as in (1) except that the search begins + N characters from the beginning of the next line, where N is + the number of spaces of indent. + + 4c. If the indent does not extend beyond the first tabstop, and + the number of spaces of indent exceeds the number of + characters on the next line (not including any leading white + space), then it beeps and moves the cursor to the end of the + next line. + +I think that's enough to show that the macro is rather inconsistent in +its behaviour. I can suggest a number of improvements: + + If "wb" is used instead of "lb", then it will not fail at the end + of a line, except on the last line of the file. + + If "deu" is used instead of "yw", then white space following the + word will not be included in the search. + + If "o^[pI/^[" is used instead of "o/^[p", then it will work properly + when autoindent is set and the current line is indented. + + If "mx" is added at the start of the macro and "`x" is added before + the "@x", then the search will start from the current cursor + position instead of from the beginning of the next line (or the + current line if it is the last line of the file). + +Moral: there's more to writing good vi macros than you might think. +-- +Geoff Clare (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 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: + + +a file1 set tags=tags1|/pattern for a/ +b file1 set tags=tags1|/pattern for b/ +c file1 /pattern for only occurrence of c/ +... + + +a file2 set tags=tags|/pattern for second a/ +b file2 set tags=tags2|/pattern for second b/ + + +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 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 @@ -0,0 +1,697 @@ +From stanj@hpnmdla.sr.hp.com (Stan Jaffe) +Newsgroups: comp.editors +Subject: Using shell filters in VI +Date: 2 Dec 91 19:34:13 GMT +Status: O + +This has always puzzled me. Perhaps someone out there knows the answer +to this: + + When using the ! 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' 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 +: + +| 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 +---------- + + +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 + +:g// + +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 @@ -0,0 +1,441 @@ +From wagner@hatteras.cs.unc.edu (Michael Wagner) +Subject: vi (including file name) +Date: 9 Jan 92 20:47:44 GMT +Status: RO + + +I'm working on a macro (in vi) that would allow me +to automatically write the name of the file into +the current cursor location in the file. + +I know that "%" seems to be the name of the file, +it seems that you can rename a file with + + :w %.new + +I think I could usually simulate what I want with a + :r !ls % + +but there has to be a better way. + +Mike + + +From steinbac@hpl-opus.hpl.hp.com (Guenter Steinbach) +Subject: Re: vi (including file name) +Date: 10 Jan 92 23:41:01 GMT +Status: O + +In comp.editors, wagner@hatteras.cs.unc.edu (Michael Wagner) writes: + + +> I'm working on a macro (in vi) that would allow me +> to automatically write the name of the file into +> the current cursor location in the file. +Yes! I'd like that also. Right now all I can do is ^G to display the +name, then cut it with the mouse (under X11) and paste it where I need +it. But a macro would be so much nicer. + +> I think I could usually simulate what I want with a +> :r !ls % +Usually, but not before the file has been written, else instead of +"filename" you'll get "filename not found". + + Guenter Steinbach steinbac@hpl-opus.hpl.hp.com + + +From dattier@gagme.chi.il.us (David W. Tamkin) +Subject: Re: vi (including file name) +Date: 10 Jan 92 23:30:03 GMT +Status: O + +wagner@hatteras.cs.unc.edu (Michael Wagner) wrote in <8656@borg.cs.unc.edu>: + +| I'm working on a macro (in vi) that would allow me +| to automatically write the name of the file into +| the current cursor location in the file. + +:r !echo % will write it below the current line, and +:-r !echo % will write it above the current line. + +David W. Tamkin Box 7002 Des Plaines, Illinois 60018-7002 +1 708 518 6769 +dattier@gagme.chi.il.us CIS: 73720,1570 MCI Mail: 426-1818 +1 312 693 0580 + + +From ttobler@unislc.uucp (Trent Tobler) +Subject: Re: vi (including file name) +Date: 13 Jan 92 17:40:53 GMT +Status: O + +steinbac@hpl-opus.hpl.hp.com (Guenter Steinbach) writes: +> In comp.editors, wagner@hatteras.cs.unc.edu (Michael Wagner) writes: +> +> +> > I'm working on a macro (in vi) that would allow me +> > to automatically write the name of the file into +> > the current cursor location in the file. +> +> Yes! I'd like that also. Right now all I can do is ^G to display the +> name, then cut it with the mouse (under X11) and paste it where I need +> it. But a macro would be so much nicer. +> +> > I think I could usually simulate what I want with a +> > :r !ls % +> Usually, but not before the file has been written, else instead of +> "filename" you'll get "filename not found". + +would + :r !echo % +work? + + +-- + Trent Tobler - ttobler@csulx.weber.edu + + +From gerolima@netlabs.com (Mark Gerolimatos) +Subject: VI: Changing case for an entire word...how did I do it? +Date: 19 Jan 92 01:58:39 GMT +Status: O + + + +Somehow, I managed to do this by accident. Just now, I did it again. +And the damned thing is that I don't know how! + +Now, '~' will toggle the case of a character, but it seems to be immune to the +standard VI [count] command [address modifier] syntax (i.e. '~w' will toggle +the case of the current character, and then move on to the next word). + + + How did I do this? + +If possible, please respond via mail... +-Mark +P.S. If it's in the manual, I couldn't find it... +====================================Cut Here==================================== +gerolima@neon.stanford.edu "Righteousness comes ONLY from Jesus Christ... + @netlabs.com ...NEVER from an apron." + -Jack T. Chick +================================================================================ + + +From gregg@cbnewsc.cb.att.com (gregg.g.wonderly) +Subject: Re: How do I... (vi or awk question, perhaps?) +Date: 25 Jan 92 00:02:07 GMT +Status: O + +>From article <1992Jan16.215423.11078@ux1.cso.uiuc.edu>, by weller@osiris (Bonnie Weller): +> For instance, my vi file looks like this... +> +> Field 1 Field 2 +> Record# Coorx Coory +> +> 1 1234 4321 +> 2 1111 4444 +> 3 2222 3333 +> +> +> I want it to look like this.... +> +> Field 1 Field 2 Field 3 +> Record# Coorx Coory Label +> +> 1 1234 4321 1 +> 2 1111 4444 2 +> 3 2222 3333 3 + + +Two people have suggested using awk, and their solutions involve doing +something with an intermediate file. From within vi, you can filter +your file by doing the following. On the top line of your +file, add the following line. + +!Gawk '{printf "\%s\%8d\n", $0, NR}' + +Next type + + 1G"ayy + +to put the top line (the one with awk on it) into the buffer a. +Next, put the cursor at the beginning of the first line of data +that you want to change. Then, type + + @a + +to tell vi to eat the contents of buffer a as keystrokes you have typed. +If you don't like the spacing, type a 'u' to undo the changes, and change +the '%8' to be '%5', or something. Then start over at "Next type" +above. + +Filtering and using the named buffers as macros are very useful parts +of vi. Knowing how to use them can save you many hours of work... + +-- +----- +gregg.g.wonderly@att.com (AT&T bell laboratories) + + +From lwv26@cas.org (Larry W. Virden) +Subject: Re: .exrc location(s) +Date: 25 Jan 92 15:53:13 GMT +Status: O + +In article <1992Jan24.211333.18456@jpradley.jpr.com> jpr@jpradley.jpr.com (Jean-Pierre Radley) writes: +:In article <1992Jan24.001030.8749@samba.oit.unc.edu> uevans@med.unc.edu (Elizabeth A. Evans) writes: +:>So why am I finding that the file has to be in (or linked to) every +:>subdirectory I'm in during a vi session? Is there some other way +:>I should do it? +: +:Try putting it into your $HOME directory; vi looks there too. +: +:I don't use a .exrc file, since it's alledgedly quicker to put the information +:into an EXINIT environment variable, which I do in my .profile or .login. +: +:You can "localize" your vi macros, if the last thing in your $HOME/.exrc, or in +:your EXINIT, is ":so .exrc+". Then you can have a different .exrc+ in your +:directory for for new C code; in your directory for mail, etc. Most often, the +:kind of macros I'd put in a .exrc+ would concern sw and wm. + +1. I dont know why some folks on Suns seem not get to their ~/.exrc used, +unless they have EXINIT set to "" - it should be unset altogether! + +2. A warning about many vi's that I have used. It appears that the .exrc +handling isnt too smart. For instance, if you edit a file in your HOME +directory - .exrc gets read twice (once as your HOME exrc and once for your +local perhaps?). Well, so what? If you have a lot of macros defined in +your HOME/.exrc, you will find you start getting error msgs when you edit +in your HOME directory - you run the macro code out of buffer space. The +thing is, if you have the same macro defined IDENTICALLY (or any other way) +both definitions appear in vi's macro buffer - I believe he only executes +the last one - but the others are still there. + +Sigh. +-- +Larry W. Virden UUCP: osu-cis!chemabs!lwv26 +Same Mbox: BITNET: lwv26@cas INET: lwv26@cas.org +Personal: 674 Falls Place, Reynoldsburg,OH 43068-1614 +America Online: lvirden + + +From jpr@jpradley.jpr.com (Jean-Pierre Radley) +Subject: Re: vi macro def at startup +Date: 26 Jan 92 18:57:42 GMT +Status: O + +In article sjreeves@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@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@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@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 @@ -0,0 +1,1456 @@ +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 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 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 <> + + +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 , 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 -key with +Date: 11 Feb 92 18:17:02 GMT +Status: O + +I'm using a VT420 terminal an I want to redefine the -Key during +an vi-session with two blanks. +TERM=vt100 + +I tried: + + :set list + :map! ^I + ^^^- 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 , 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 -key with +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 -Key during +>an vi-session with two blanks. +>TERM=vt100 +> +>I tried: +> +> :set list +> :map! ^I +> ^^^- 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 + ^^^- three blanks + +To get the CTRL's right: + +:map! + +\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@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@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 -key with +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 -key with +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 -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! + +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 +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 +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 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 @@ -0,0 +1,950 @@ +From tab@ibmpcug.co.uk (Andrew Beattie) +Subject: regular expression puzzle +Date: 2 Mar 92 18:14:01 GMT + +I want to be able to take this input: +----------------------------------------------------------------------------- +some text [delete_this_bit ] some more text +----------------------------------------------------------------------------- +and change it to this: +----------------------------------------------------------------------------- +some text [ ] some more text +----------------------------------------------------------------------------- +By specifying that I want to replace all the characters within the "[]" +delimeters with spaces. Can it be done in one shot with a regular +expression? I am currently doing it one character at a time, thus: +----------------------------------------------------------------------------- +sed ' +:again +s/\(\[ *\)[a-zA-Z_0-9]/\1 / +t again +' +----------------------------------------------------------------------------- +but surely there must be a neater way? + +Andrew +-- + + +From gummitch@techbook.com (Jeff Frane) +Subject: vi question--scrambled long lines +Summary: How to deal with over-long lines? +Keywords: vi +Date: 2 Mar 92 18:33:11 GMT + +Two questions, really. + +1 Does anyone have any good vi documentation they can e-mail me? I +have no way of retrieving anything by ftp. + +2 What can I do about lines that get mangled when I attempt to reply, +either to e-mail or to a posting. These seem to occur when the original +writers are working on a wide terminal. The resulting lines get chopped +off, or worse, the terminal here starts writing lines way over on the +right margin. + +--Jeff Frane + +-- +gummitch@techbook.COM Public Access UNIX at (503) 644-8135 (1200/2400) +"You must allow that drunkenness, which is equally destructive to body +and mind, is a fine pleasure." Lord Chesterfield, writing to his son + + +From jtwiss@isis.cs.du.edu (Justin Twiss) +Subject: Vi query +Summary: Help with a VI Search command +Keywords: vi search vowels +Date: 29 Feb 92 14:28:22 GMT + + +Greetings one and all... + +Just a quick question, one of my lecturers at tech has set me a smalkl +task that I'm having a bit pof a problem with... + +Using VI's search commandss, create a serarch line that would only +locate words that started and ended with a vowel.... + +I've spent three weeks on this and have just about given up in disgust.. + +Any ideas? + + +Justin... +jtwiss@isis.cs.du.edu + + +From fitz@mml0.meche.rpi.edu (Brian Fitzgerald) +Subject: Re: Vi query +Keywords: vi search vowels +Date: Sun, 1 Mar 1992 06:14:44 GMT + +Justin Twiss writes: + +>Using VI's search commands, create a search line that would only +>locate words that started and ended with a vowel.... + +Try + +/\<[aeiouAEIOU][^ tab]*[aeiouAEIOU]\> or, +/\<[aeiouAEIOU][a-zA-Z']*[aeiouAEIOU]\> + +See ed(1). Adjust the middle [] to suit. Fails for single letter +words like "a" or "I". Sorry. + +Brian + + +From krm@pri-mu.prime.com (Martin {martlbub} Kraegeloh) +Newsgroups: comp.unix.questions +Subject: Re: vi query +Date: 2 Mar 92 22:17:21 GMT + +> Justin Twiss () 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 for an +arbitrary line is given by: + + = 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 + +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@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 .c, how do I, with one keystroke, edit file .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 .c, how do I, with one keystroke, edit file .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 .c, how do I, with one keystroke, edit file .h ? +>Is there some way of getting the output of 'file' or '%' into a buffer ? + +Start your editing session with: + + vi .c .h + +After you have finished with .c the first time, type + + :n + +to edit .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 .c, how do I, with one keystroke, edit file .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 .c, how do I, with one keystroke, edit file .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 @@ -0,0 +1,97 @@ +This file contains the INDEX of the Comp.Editor tips collection. +The index is created by running a grep(1) on the Subject. + +The various tips files can easily be acessed via the standard Berkeley +mailinterface: + mail -f ced.tips.1 + +When I have the time, I exstract some of the subject presents, and put +them in separate files. But this will probably not happen before +easter '92 ;-). + + +ced.tips.1 + In vi: How to delete from str1 to str2 ? + In vi: How do I put line numbers in frant of each line ? + writing from buffers + How to disable 'vi' beep? + Tabs as spaces in VI. + vi question - am I so different? + vi question, replace second occurence + removing first field from a number of lines with vi + Smart 'C' editors?!? + vi question, replace second occurence + filling paragraph in vi + +ced.tips.2 + Quoting in ex/vi -- more info + Vi and Tags file...(please help). + piping in an ex keymap + EX / VI delete up-to and including + What does this do? (was Vi internal design doc. needed) + Fun with tags + VI search for begin/end of blocks + how do I macroize c --> |c| + Addressing lines in vi and ex + +ced.tips.3 + Using shell filters in VI + VI: Freeing macro space for map command + How do do these things in vi? + How do you do these things in vi? + vi window scrolling + How to change timeout length in vi without timeoutlen ? + ctrl-u in vi + vi window scrolling (vt100) + Reverse video in vi + Going crazy with non-vi DOS editor + ex command to delete blank lines + vi (including file name) + +ced.tips.4 + vi (including file name) + VI: Changing case for an entire word...how did I do it? + How do I... (vi or awk question, perhaps?) + .exrc location(s) + vi macro def at startup + Octal code quotation in vi search & replace? + +ced.tips.5 + Good names for vi macros + do I ignorecase when using a TAGs file? + Tabs and Blanks + easy vi question: how to 'grep -v /r.e/' + vi question + vi - redefine -key with + 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 @@ -0,0 +1,138 @@ + + +From mgflax@phoenix.Princeton.EDU (Marshall G. Flax) +Subject: Re: Command line editing in vi +Date: 12 Aug 92 06:32:11 GMT + +In article <1992Aug12.021145.5902@nuscc.nus.sg> ccechk@nuscc.nus.sg (Heng Kek) writes: +>Imagine entering something like +> :'a,$s/\([a-z]*\).*\([0-9]\) *[^ ]*)/\2,\1==/ +>only to find that you've missed a '('. +> +>I hope there's an answer which I presume lies in macros. + +One solution is to actually enter that line into your text and edit it +until it is perfect. Then yank it into a named buffer + "zdd +and execute it + @z + +If you need to fix it, you can pull it back from the named buffer, + "zp +re-edit, re-yank, and then re-execute it. + + +marshall + +-- +------- (c) 1992, Marshall Gene Flax ------- +----------- 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 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 @@ -0,0 +1,25 @@ +From kevinl@tisdec.tis.tandy.com +Date: 18 Aug 92 09:08 CDT +Subject: Re: Switching cols in VI + + + If you don't want to worry about how many columns you have, +you can use the following awk program. + + +{ + for( i = 0; i < NF; i++ ) { + printf "%s", $(NF - i) + if( i != NF - 1 ) + printf " " + } + print "" + +} + +It just starts at the end and works backwards. The 'if' is there +so that it doesn't put spaces at the end of your lines. Hope this +helps you out. 8-) + + + blob - /dev/null blob + a5a842acf40627b6c590a48027ebdf34a2d949db (mode 644) --- /dev/null +++ comp.editors/columedit @@ -0,0 +1,28 @@ +From riskit@x400gate.bnr.ca (Reg Foulkes) +Subject: Re: Using vi to edit columns (was Re: Why I love VI) +Date: Thu, 13 Aug 1992 13:38:45 GMT + +In article , gwc@root.co.uk (Geoff Clare) wrote: +> +> In 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 @@ -0,0 +1,50 @@ +From jimr@applix.com (Jim Rouleau [ext 256]) +Subject: Counter in VI? +Date: 13 Aug 92 14:15:38 GMT + +Is there any way to implement a counter in VI? +What I'd like to do is take something like this: + + #define a 1 + #define b 2 + #define c 3 + . + . + #define z 26 + + to become + + #define a 0 + #define b 1 + #define c 2 + . + . + #define z 25 + +Any way to do this besides manually?? + + jimr + + +From mgflax@phoenix.Princeton.EDU (Marshall G. Flax) +Subject: Re: Counter in VI? +Date: Thu, 13 Aug 1992 17:02:13 GMT + +In article <1623@applix.com> jimr@applix.com (Jim Rouleau [ext 256]) writes: +>What I'd like to do is take something like this: +> +> #define z 26 +> to become +> #define z 25 + +Pipe the relevant lines through awk! (Although, if you're really only +concerned with changing #defines, compilers will generate exactly the +same code given + #define z (26-1) +as if they received + #define z 25 +and the addition of the parenthesis et.al. can clearly be done within vi.) + +marshall +-- +------- (c) 1992, Marshall Gene Fla \ No newline at end of file blob - /dev/null blob + 4c2574ca1440030540e6915980d8ae2b7d331bc3 (mode 644) --- /dev/null +++ comp.editors/countwords @@ -0,0 +1,60 @@ +From cjlin@math.ntu.edu.tw () +Subject: How to count words ? +Date: Sat, 3 Jul 1993 02:13:38 GMT + +Dear netters : + +Could someone tell me how to count the number +of words in Vi or under UNIX shell ? + +Thanks in advance. + +Chih-Jen Lin +Dept. of Math. +National Taiwan Univ. + + +From markhof@ls12r.informatik.uni-dortmund.de (Ingolf Markhof) +Subject: Re: How to count words ? +Date: 3 Jul 1993 12:15:30 GMT + +In article <1993Jul3.021338.16304@ccds3.ntu.edu.tw>, cjlin@math.ntu.edu.tw () writes: +|> Could someone tell me how to count the number +|> of words in Vi or under UNIX shell ? + +Yes, that's easy: Just type + + :!wc -w % + +in command mode to get the number of words, or + + :!wc % + +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 @@ -0,0 +1,62 @@ +From buboo@alf.uib.no (Ove Ruben R Olsen) +Subject: Re: How do I remove new-lines [CR,LF] in vi? +Date: Mon, 20 Jul 92 08:54:26 GMT + +Sergio Stewart writes: +>How do I remove a CR,LF from a file while editing with vi? +>In the past Ive "dd" the entire line just to remove the CR,LF. +>I know it is possible to use "u" undo the CR,LF is still in the +>buffer, but what if it isnt? What Id like is a simple "x" [delete char] +>solution to removing CR and LF's. +> +>Any ideas? + +To remove the CRLF at the end of a line: :%s/^V^M// + ^ + CTRL-V-CTRL-M + +To remove blanklines (LF): :%s/^$// + ^ + NOT CTRL-$, but just ^ and $ + +To remove blanklines containing ^M (CRLF): :%s/^^V^M$// + + +\Ruben. + + +-- + Ove Ruben R Olsen, Professional VI user. EMAIL: Ove.R.Olsen@ubb.uib.no + Maintaining the Largest VI/EX-STUFF Archive in the WORLD (alf.uib.no) and +the Comp.Editors FAQ file. If you have information about editing, new editors, + please get in touch with me. This does not apply to EMACS type of editors. + + +From hansm@cs.kun.nl (Hans Mulder) +Subject: Re: How do I remove new-lines [CR,LF] in vi? +Date: Mon, 20 Jul 1992 10:03:00 GMT + +In 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 @@ -0,0 +1,62 @@ +From: fisher@inls1.ucsd.edu (Yuval Fisher) +Newsgroups: comp.editors +Subject: Vi/Ex: command line editor? - Yes! +Date: 16 Sep 92 17:14:48 GMT +Organization: Institute for Nonlinear Science +Lines: 54 + +Quite some time ago ian@unipalm.uucp (Ian Phillipps) wrote +about a handy way to set up a csh command line editor using vi. +I have been using it faithfully, until my vi changed from +"Version 3.7, 6/7/85." to "Version SVR3.1". Now, things are screwy +and it basically doesn't work. Does anyone know how to fix this +problem (other than switch away from csh or change vi) ? Incidentally, +I consider this command line editor thingy to be the best thing since, +say, money subplanted bartering ? + +I include Ian's posting below, since it is short: + +The following works with the C-shell. It was posted about two years ago +on Usenet, and the poster then said that its origin was lost in the +mists of time. Here goes: + +You need an alias in your normal setup, thuswise: + + alias r source ~/cmd/redo + +Type "r" and you'll be in "vi" open mode, editing the last command. You can +use any vi/ex commands (even go into visual mode): when you hit Return, the +current line will be executed by the C shell. + +The "redo" file is as follows. **IMPORTANT NOTE** To avoid mangling in +the posting, I've replaced a Carriage Return with "^M" and an ESC with "^[" +in ex's "map" command: + +----cut here and replace control characters--- +# Edit history list at line containing last command (open mode). +# Get up to 22 most recent commands. +# To work properly, put in .login: alias r source /usr/local/bin/redo +# Author unknown. +history -h 22 >! /tmp/redo.$$ + +# Make CR map to :wq! and start ex quietly at 2nd to last line in open mode. +ex - '+map ^M :.wq\!^[|set redraw|$-1 open' /tmp/redo.$$ + +# Insert into history without executing. +source -h /tmp/redo.$$ + +# Clear out temporaries. +/bin/rm -f /tmp/redo.$$ + +# If thing chosen to redo is the redo alias itself then DON'T redo it. +if (!-2:0 != !!:0) !! +----cut here---- + + +--------------------------------------------------------------------- +Yuval Fisher e-mail: yfisher@ucsd.edu +Institute for Non-Linear Science 0402 +University of California, San Diego +La Jolla, CA 92093 +--------------------------------------------------------------------- + blob - /dev/null blob + 211b9be6ce85299f3bd14963b0e22235d7e8e65a (mode 644) --- /dev/null +++ comp.editors/ctrl @@ -0,0 +1,136 @@ +From govind@infonode.ingr.com (Govind Vadvadgi) +Subject: vi: How to type S and ^Q in ascii file? +Date: Wed, 22 Jul 1992 20:34:18 GMT + +I was wondering if there is way to type Q ( Cntrl-Q ) and S ( Cntrl-S ) +in an ascii file. ( I can type other charecters like , , etc. ) + +Thanks in advance. +-- +-Govind. + govind@infonode.ingr.com + + +From hello@cs.utwente.nl (Ronald Hello) +Subject: Re: vi: How to type S and ^Q in ascii file +Reply-To: hello@cs.utwente.nl +Date: Wed, 29 Jul 1992 11:30:43 GMT + +In article JFn@news.cso.uiuc.edu, gordon@osiris.cso.uiuc.edu (John Gordon) writes: +rh> +rh> In vi, to enter any control character, first type Control-V, then +rh>the desired control character. For example, to enter a Control-Y, you +rh>would type: Control-V Control-Y + +Seems to me he asked especially about Control-Q and Control-S, not about your +average Control character. Try it on a Sun, in vi with Control-S. I posted this +as a question here some time ago and it seems it's NOT possible on HP's and +Sun's for Control-S. Some machines will do it though. The Sun will do +it in the csh and sh (don't know about other shells) but not in vi, the +HP won't do it at all. + +rh> +rh>--- +rh>John Gordon My incredibly witty saying has been +rh>gordon@osiris.cso.uiuc.edu Politically Corrected into oblivion. + +Ronald. + + +--- +__ +// Ronald Hello (hello@cs.utwente.nl) +// Department of Computer Science +// University of Twente +// The Netherlands + + + +From lange@obelix.pcs.dec.com (Ralf Lange Digital-PCS GmbH) +Subject: Re: Q: Inputting an Escape Sequence w/VI +Reply-To: lange@obelix.pcs.dec.com (Ralf Lange Digital-PCS GmbH) +Date: Wed, 14 Jul 1993 13:06:55 GMT + + +go into insert mode and type + +^V^[ + +every time you want to place the escape character +in your text. '^V' means CTRL-V and '^[' is the Escape key. + +Ralf + + +From hansm@wsinti06.info.win.tue.nl (Hans Mulder) +Subject: Re: Q: Inputting an Escape Sequence w/VI +Date: 14 Jul 1993 16:50:33 +0200 + +In <147620001@capella.cup.hp.com> alicef@capella.cup.hp.com (Alice Farrelly) writes: + +>Hi , + +>This is a quick question, + +>How do I put escape sequences in a file using vi? + +Type a control-V before the escape. + +>I want to add the following sequence to highlight some lines. +>ESC&dA ([&dA) + +That won't work on most terminals. Most terminals want something +like ESC[7m . If you want to write something that works on many +terminals, you'll have to extract the appropriate escape sequence +from the termcap (or terminfo) database. Or put a _ and a backspace +in front of every highlighted character, and let a program like more +(or ul, or less) figure it out. + +To put a backspace in a file using vi, you have to type a control-V +before the backspace. + +HansM + + +From ray@Celestial.COM (Ray Jones) +Subject: Re: Q: Inputting an Escape Sequence w/VI +Date: Wed, 14 Jul 1993 16:27:20 GMT + +In <147620001@capella.cup.hp.com> alicef@capella.cup.hp.com (Alice Farrelly) writes: + +>Hi , + +>This is a quick question, + +>How do I put escape sequences in a file using vi? + +>I want to add the following sequence to highlight some lines. +>ESC&dA ([&dA) + + +This is the vary standard way to include any unprintable character in a +vi file. While in the input mode, enter a Control-V, followed by the +charater you wish to enter. For your example: +Control-V ESC &dA +and it will look like +^[&dA +-- +INTERNET: ray@Celestial.COM | The probability of one or more +Ray A. Jones; Celestial Software | spelling errors in this missive +8545 S.E. 68th Street | approaches unity. If this bothers you, +Mercer Island, WA 98040;(206) 236-1676 | run it through your spell checker! + + +From brandari@anl433.uucp (Paul Brandariz x6546) +Subject: Re: Q: Inputting an Escape Sequence w/VI +Date: Wed, 14 Jul 1993 15:47:36 GMT + +Control-V will tell vi to take the next character as is. This is how +you can enter the ESC character. + +-- +___________________________________________________________________________ +Paul R. Brandariz E-mail Internet: paul.brandariz@kla.com +KLA Instruments Corp +P.O. Box 49055 Voice: (408) 456-6546 +San Jose, CA 95161-90 \ No newline at end of file blob - /dev/null blob + f27b59f949cec77fc20746620bbaae73d4a58599 (mode 644) --- /dev/null +++ comp.editors/currfn @@ -0,0 +1,34 @@ +From g88m0396@alpha.ru.ac.za (Jon-Dean Mountjoy) +Subject: Grab current Filename in VI? +Date: Mon, 28 Jun 1993 17:54:07 GMT + +Hello + +I want to be able to grab the current filename that I am editing, +so that (in a macro), I can say, LaTeX the CURRENT file, +or Ispell the CURRENT file. Something like +map lat :!latex $$ +where $$ is the current file that VI is editing. + +Thanks + +Jon-Dean + +-- +------------------------------------------------------------------------------- + Jon-Dean Mountjoy csjm@beta.ru.ac.za Rhodes University + The views herein are my own + and not those of the institution + + +From hrjoist@immd4.informatik.uni-erlangen.de (Holger Joist) +Subject: Re: Grab current Filename in VI? +Date: Mon, 28 Jun 1993 19:01:04 GMT + +g88m0396@alpha.ru.ac.za (Jon-Dean Mountjoy) writes: + +>I want to be able to grab the current filename that I am editing, +>so that (in a macro), I can say, LaTeX the CURRENT file, +>or Ispell the CURRENT file. Something like +>map lat :!latex $$ +>where $$ is the current \ No newline at end of file blob - /dev/null blob + 4e13a008399ffabba14c88bc4497a7d66b30e380 (mode 644) --- /dev/null +++ comp.editors/cutpaste @@ -0,0 +1,914 @@ +From bhoughto@sedona.intel.com (Blair P. Houghton) +Subject: Re: vi (cut and paste) +Date: Mon, 17 Aug 1992 17:04:16 GMT + +In article <3815@keele.keele.ac.uk> phd85@seq1.keele.ac.uk (D.H. Holden) writes: +> Does anyone know how you cut a range of text to one +> of the named buffers, where the range does not cover +> an integer number of lines, i.e., +> How do i cut from here > text text text .......... +> ............... n number of lines ..... +> ...... to here < into the named buffer "a for example? + +Go to one end of the range and set a mark, then go to the +other end and buffer-yank-to-marked-character, using +double-quote and back-tick; for example, (the mark is "a" +and the buffer is "f", the first letter in the range is the +"b" in "bazz" and the last is the double-quote before the +"b" in "bar"): + + /bazz + ma <-- set the mark + /bar + "fy`a <-- yank to marked character + /result + nn"fp + +The result is: +The rbazz" and the last is the double-quote before the +"b" in "esult is: + + + --Blair + "Cake." + + +From bibb@s912%bnf.com (Ken Bibb) +Subject: Re: vi (cut and paste) +Date: 17 Aug 92 20:01:49 GMT + +In <3815@keele.keele.ac.uk> phd85@seq1.keele.ac.uk (D.H. Holden) writes: + + +> hi, +> Does anyone know how you cut a range of text to one +> +> of the named buffers, where the range does not cover +> +> an integer number of lines, i.e., + +> How do i cut from here > text text text .......... + +> ............... n number of lines ..... + +> ...... to here < into the named buffer "a for example? + +> Cheers, + +> Dave. + +In the following texT: + +aaabbbbbb +bbbbbbbbb +bbbbccccc + +I'll assume you want to cut the b's out and save them into buffer a. + +1) position the cursor at the beginning of the range to be cut (1Gfb will work + in this example). +2) ma (mark the location with marker a) +3) move to the end of the range (Gfc will work in this example) +4) "ad`a will cut the range and put it into buffer a + +-- +ken@bnf.com jester@crash.cts.com +-- +bnf!s912!ken@crash.cts.com "The Fire and the Rose are one"--T.S.Eliot + + +From sgr@alden.UUCP (Stan Ryckman) +Subject: Re: vi (cut and paste) +Date: 19 Aug 92 16:40:04 GMT + +In article <1992Aug17.200149.7817@s912%bnf.com> bibb@s912%bnf.com (Ken Bibb) writes: +>In <3815@keele.keele.ac.uk> phd85@seq1.keele.ac.uk (D.H. Holden) writes: +>> hi, +>> Does anyone know how you cut a range of text to one +>> of the named buffers, where the range does not cover +>> an integer number of lines, i.e., +>> How do i cut from here > text text text .......... +>> ............... n number of lines ..... +>> ...... to here < into the named buffer "a for example? +>> Cheers, +>> Dave. +>In the following texT: +>aaabbbbbb +>bbbbbbbbb +>bbbbccccc +> +>I'll assume you want to cut the b's out and save them into buffer a. +>1) position the cursor at the beginning of the range to be cut (1Gfb will work +> in this example). +>2) ma (mark the location with marker a) +>3) move to the end of the range (Gfc will work in this example) +>4) "ad`a will cut the range and put it into buffer a + +NOT! + +This grabs all three full lines. (I tried it! Did you?) + +Dave presumably wants to have the remaining text be: +aaaccccc + +and the buffer to contain: +bbbbbb +bbbbbbbbb +bbbb + +"Mark" (the "m" command) only marks the line, NOT the cursor +position within the line. + +In this trivial example, the following works: +1) position to the beginning as Ken suggests (1Gfb); +2) type the command "ad/c + which will delete up to the first "c" character, putting the + deletions into the buffer. + +However, in the general case this doesn't work; suppose you +want all the b's PLUS the first c to be cut. Then, + "ad2/c +won't work (vi doesn't allow a number before the / command). +Yes, here you could do + "ad/cccc$ +and, in most cases, something can be found to work. But to my +mind, there's no way to put the cursor at one arbitrary mid-line +point, type something, then position to another arbitrary mid-line +point, and then delete the in-between-text into a named buffer. + +Am cross-posting to comp.editors, since someone there may know +for sure whether there _is_ a way to do this, and if I'm wrong I'd +like to know. But please, _TRY_ it before posting! + +Stan. +-- +This .signature has expired. Call 1-900-YOU-FOOL to find out why. + Stan Ryckman sgr@alden.UUCP + + +From asoper@wyvern.twuug.com (Aubrey Soper) +Subject: Re: vi (cut and paste) +Date: 18 Aug 92 20:34:41 GMT + +phd85@seq1.keele.ac.uk (D.H. Holden) writes: + + +> hi, +> Does anyone know how you cut a range of text to one +> +> of the named buffers, where the range does not cover +> +> an integer number of lines, i.e., + +> How do i cut from here > text text text .......... + +> ............... n number of lines ..... + +> ...... to here < into the named buffer "a for example? + +> Cheers, + +> Dave. + +"ad/< + +should do it. You can also mark the end and delete to +that mark. I'd recommend that you get a book on vi, such +as UNIX Text Processing by Hayden Books. With only the +UNIX docs, you'll probably wind up hating vi... + +aubrey soper + + +From sgr@alden.UUCP (Stan Ryckman) +Subject: Re: vi (cut and paste) +Date: 19 Aug 92 16:40:04 GMT + +In article <1992Aug17.200149.7817@s912%bnf.com> bibb@s912%bnf.com (Ken Bibb) writes: +>In <3815@keele.keele.ac.uk> phd85@seq1.keele.ac.uk (D.H. Holden) writes: +>> hi, +>> Does anyone know how you cut a range of text to one +>> of the named buffers, where the range does not cover +>> an integer number of lines, i.e., +>> How do i cut from here > text text text .......... +>> ............... n number of lines ..... +>> ...... to here < into the named buffer "a for example? +>> Cheers, +>> Dave. +>In the following texT: +>aaabbbbbb +>bbbbbbbbb +>bbbbccccc +> +>I'll assume you want to cut the b's out and save them into buffer a. +>1) position the cursor at the beginning of the range to be cut (1Gfb will work +> in this example). +>2) ma (mark the location with marker a) +>3) move to the end of the range (Gfc will work in this example) +>4) "ad`a will cut the range and put it into buffer a + +NOT! + +This grabs all three full lines. (I tried it! Did you?) + +Dave presumably wants to have the remaining text be: +aaaccccc + +and the buffer to contain: +bbbbbb +bbbbbbbbb +bbbb + +"Mark" (the "m" command) only marks the line, NOT the cursor +position within the line. + +In this trivial example, the following works: +1) position to the beginning as Ken suggests (1Gfb); +2) type the command "ad/c + which will delete up to the first "c" character, putting the + deletions into the buffer. + +However, in the general case this doesn't work; suppose you +want all the b's PLUS the first c to be cut. Then, + "ad2/c +won't work (vi doesn't allow a number before the / command). +Yes, here you could do + "ad/cccc$ +and, in most cases, something can be found to work. But to my +mind, there's no way to put the cursor at one arbitrary mid-line +point, type something, then position to another arbitrary mid-line +point, and then delete the in-between-text into a named buffer. + +Am cross-posting to comp.editors, since someone there may know +for sure whether there _is_ a way to do this, and if I'm wrong I'd +like to know. But please, _TRY_ it before posting! + +Stan. +-- +This .signature has expired. Call 1-900-YOU-FOOL to find out why. + Stan Ryckman sgr@alden.UUCP + + +From ianh@nmpd.oz.au (Ian Holland) +Subject: Re: vi (cut and paste) +Reply-To: ianh@nmpd.oz.au +Date: 20 Aug 92 03:04:48 GMT + +sgr@alden.UUCP (Stan Ryckman) writes: + +>In article <1992Aug17.200149.7817@s912%bnf.com> bibb@s912%bnf.com (Ken Bibb) writes: +>>In <3815@keele.keele.ac.uk> phd85@seq1.keele.ac.uk (D.H. Holden) writes: +>>> hi, +>>> Does anyone know how you cut a range of text to one +>>> of the named buffers, where the range does not cover +>>> an integer number of lines, i.e., +>>> How do i cut from here > text text text .......... +>>> ............... n number of lines ..... +>>> ...... to here < into the named buffer "a for example? +>>> Cheers, +>>> Dave. +>>In the following texT: +>>aaabbbbbb +>>bbbbbbbbb +>>bbbbccccc +>> +>>I'll assume you want to cut the b's out and save them into buffer a. +>>1) position the cursor at the beginning of the range to be cut (1Gfb will work +>> in this example). +>>2) ma (mark the location with marker a) +>>3) move to the end of the range (Gfc will work in this example) +>>4) "ad`a will cut the range and put it into buffer a + +>NOT! + +I think I have worked out the English translation for this exclamation :-) + +>This grabs all three full lines. (I tried it! Did you?) + +The given example works with SunOS's vi. Perhaps you have an inferior +version (though this makes me sick in the stomack when I think about it), +or maybe (just maybe) you used ' instead of `. + + . + . + . + +>"Mark" (the "m" command) only marks the line, NOT the cursor +>position within the line. + +This is totally incorrect. + +>Am cross-posting to comp.editors, since someone there may know +>for sure whether there _is_ a way to do this, and if I'm wrong I'd +>like to know. But please, _TRY_ it before posting! + +Yes I did try the original (valid) suggestion before you read this. + +best of luck, +-- + +- ian... + +Ian Holland. NMPD, Telecom. % Ph: +61 7 837 5075 % Explicit hoc totum, +E-Mail: ianh@nmpd.oz.au % Fax: +61 7 837 5253 % Pro Christo da mihi potum! + + + +From smr@hitkw14.pki-nbg.philips.de (S.Riehm) +Subject: Re: vi (cut and paste) +Date: 20 Aug 92 07:03:22 GMT + +phd85@seq1.keele.ac.uk (D.H. Holden) writes: + + +> hi, +> Does anyone know how you cut a range of text to one +> +> of the named buffers, where the range does not cover +> +> an integer number of lines, i.e., + +> How do i cut from here > text text text .......... + +> ............... n number of lines ..... + +> ...... to here < into the named buffer "a for example? + +as soon as you mention the word "lines" in vi you get complete lines +only! + +However, You can specify a search pattern, or any movement pattern, so +you could move the cursor to the start position, then type; +"ay/< into/^M + +using your examply above. This will yank everything up to but not +including the string in the search pattern. + +you could also do stupid things like: +"ay120W +which would yank the next 120 blank separated words. + +This works for delete, change, >> << etc etc also. + +good luck + +----------------------------------------------------------------- +Stephen Riehm Configuration Management _-_|\ +smr@pki-nbg.philips.de Philips Kommunikations Industrie / \ +Work: +49 911 526 2975 Nuernberg, Germany \_.-.*/ +Fax: +49 911 526 2095 "I was there, now I am here!" v +"My company speaks another language, I CAN'T speak on it's behalf" + + +From hansm@cs.kun.nl (Hans Mulder) +Subject: Re: vi (cut and paste) +Date: Thu, 20 Aug 1992 15:35:18 GMT + +In <515@alden.UUCP> sgr@alden.UUCP (Stan Ryckman) writes: +>In article <1992Aug17.200149.7817@s912%bnf.com> bibb@s912%bnf.com (Ken Bibb) writes: +>>In the following texT: +>>aaabbbbbb +>>bbbbbbbbb +>>bbbbccccc +>> +>>I'll assume you want to cut the b's out and save them into buffer a. +>>1) position the cursor at the beginning of the range to be cut (1Gfb will work +>> in this example). +>>2) ma (mark the location with marker a) +>>3) move to the end of the range (Gfc will work in this example) +>>4) "ad`a will cut the range and put it into buffer a + +>NOT! + +>This grabs all three full lines. (I tried it! Did you?) + +Yes. It works. What you did was "ad'a which indeed grabs three full lines. + +Maybe you have a problem distinguishing quote (') from backquote(`). They're +very similar on some displays. +If you use quote ('), you'll grab whole lines; if you use backquote(`), you'll +only grab the appropriate parts of the first and last lines. + +-- +Hope this helps + +Hans Mulder hansm@cs.kun.nl + + +From bhoughto@sedona.intel.com (Blair P. Houghton) +Subject: Re: vi (cut and paste) +Date: Thu, 20 Aug 1992 01:35:31 GMT + +In article <515@alden.UUCP> sgr@alden.UUCP (Stan Ryckman) writes: +>"Mark" (the "m" command) only marks the line, NOT the cursor +>position within the line. + +Just what sort of vi(1) are you using? + +The backtick (`) command would be useless unless the mark +(m) command marked the precise location of the cursor, and +both have worked just fine for me on the dozen or so UNIXen +on which I've had the opportunity to run vi(1). + + --Blair + "No, I won't make a crude + remark about how silly + this argument would be + in EMACS." + + +From Tom Christiansen +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 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 method allows me to use +the current position + the to delineate a block to delete +and the target is any line movement command (eg, G, / tede@alcor.concordia.ca ( TED EWANCHYNA ) writes: + +>In article 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 method allows me to use +>the current position + the to delineate a block to delete +>and the target is any line movement command (eg, G, /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 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 , +Jacques Marcoux 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 , 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 @@ -0,0 +1,286 @@ +From hansm@wsinti04.info.win.tue.nl (Hans Mulder) +Subject: Re: Demystifying vi one step further.. +Date: 29 Jun 1993 14:38:43 +0200 + +In 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 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 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 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 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 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 @@ -0,0 +1,262 @@ +From nh@cbnewsg.cb.att.com (nicholas.hounsome) +Subject: Re: UNIX COMMAND IN VI SESSION. +Date: Fri, 2 Oct 1992 07:33:09 GMT + +>From article <=1=p9lb@lynx.unm.edu>, by hamjavar@carina.unm.edu (Farid Hamjavar): +> +> Hello : OCT-01-92 +> +> VI allows you to execute UNIX commands in a VI session. +> How can I enter AT THE CURSER, the output of the UNIX's "date" command ? +> + +:map ^X i^M^[:r!date^MddpkkJJ + +This will not work correctly at the end of a line because of the two joins. + +or + +:map ^X ma:r!date^Mj0d$`apmajdd`a + +This uses d$ to delete to the end of the line but not the newline and +uses the little known but useful backquote which puts you at the marked +character position. + +There is no way to read in directly at the cursor position because +the read has to be done in ex line editor mode which does not understand +cursor position (or `). + +> +> +> ThankS a lot. +> Farid Hamjavar +> hamjavar@carina.unm.edu + +Nic Hounsome + + + +From shrchin@csug.cs.reading.ac.uk (Jonathan H. N. Chin) +Subject: Re: UNIX COMMAND IN VI SESSION. +Date: 2 Oct 92 08:29:38 GMT + +hamjavar@carina.unm.edu (Farid Hamjavar) asked: + +>VI allows you to execute UNIX commands in a VI session. +>How can I enter AT THE CURSER, the output of the UNIX's "date" command ? + +If you want the cursor to end up in the same place as it started: + +mao^[!!date^M"ad$`aPjdd`a + +where ^[ is the ESC key and ^M is the RETURN key. Alternatively to get the +cursor to finish _after_ the inserted text: + +i^M^Mx^[k!!date^MkJxJxx + +Again ^[ is ESC and ^M is RETURN. The first and last x are not needed but ensure +that no spaces are either added or deleted. + +Note that there are numerous other ways to do this operation. If you don't plan +on using the above inside a macro, you can omit the named buffers from the first +example, making it the same number of keystrokes as the second example. Or you can +omit various bits if you don't care where the cursor ends up, etc. + +Jonathan +-- +Jonathan H N Chin, 8 kyu \ Dept. of Cybernetics, \ "Respondeo, etsi mutabor" + \ University of Reading \ +shrchin@uk.ac.rdg.susssys1 \ Box 225, Whiteknights \ < Rosenstock-Huessy > +bq305@cleveland.freenet.edu \ Reading, RG6 2AY, U K \ + + +From rac@sherpa.uucp (Roger Cornelius) +Subject: Re: UNIX COMMAND IN VI SESSION. +Date: Fri, 02 Oct 1992 14:13:43 GMT + +In article <=1=p9lb@lynx.unm.edu>, hamjavar@carina.unm.edu (Farid Hamjavar) writes: +> +> Hello : OCT-01-92 +> +> VI allows you to execute UNIX commands in a VI session. +> How can I enter AT THE CURSER, the output of the UNIX's "date" command ? + +vi has no builtin way to do this. +!!date +will overwrite the contents of the current line, or +:
r !date +will insert the date at
or after the current line if +
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 +>always send two lines. + +Certainly: + + !!some_command + +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 @@ -0,0 +1,25 @@ +From dcd@tc.fluke.COM (David Dyck) +Subject: Origin of % in replacement pattern in vi +Date: 24 Jun 92 19:57:18 GMT +Article-I.D.: tc.1992Jun24.195718.16732 + +I've been using vi for a long time, but it's been a while +since I've tried the command +:s/foo/%/ + +Until now this would replace the string foo with the character '%', +but now it appears that % does something similar to the metacharacter ~ +in the replacement part of a substitute command. + +Earlier vi's did not do this, and the earlier manuals did not mention +this (Although the LATEST manual from Sun that we have (SunOS Release 4.1.2) +has added a sentence about it. + +Would someone please explain why vi was changed? + +(I have seen mentions about a ucb vs. sysV vi, is this one of the new + features of sysV?) + + David Dyck dcd@tc.fluke.COM + + blob - /dev/null blob + 3d85db51911a7589c6bf2ad81a99c418578aed01 (mode 644) --- /dev/null +++ comp.editors/insert @@ -0,0 +1,132 @@ +From saunders@luther.che.wisc.edu (Brian E. Saunders) +Subject: vi insert question +Date: 28 May 92 16:20:16 GMT + +Say I have 1000 lines of text. Before each line, I want to insert a +specific character. How do I do this with 1 command? + +Note: each line before the character is inserted does not begin with the +same character, so I can't do a simple substitution command. +-- + +Brian E. Saunders saunders@luther.che.wisc.edu + + +From snk@fork.bae.bellcore.com (Samuel N Kamens) +Subject: Re: vi insert question +Date: 28 May 92 17:58:31 GMT +Reply-To: snk@bae.bellcore.com + +In article <1992May28.112017.21007@doug.cae.wisc.edu>, saunders@luther.che.wisc.edu (Brian E. Saunders) writes: +> Say I have 1000 lines of text. Before each line, I want to insert a +> specific character. How do I do this with 1 command? +> +> Note: each line before the character is inserted does not begin with the +> same character, so I can't do a simple substitution command. +> -- + + +Try this: + + +:1,$s/^/c/ + +This says: + + :1,$ (for every line in the file) + s/^/c/ (replace the regular expression ^, which means + "beginning of line", with the character c). + +Sam + +-- +Sam Kamens Bell Communications Research +snk@bae.bellcore.com Phone: (908) 699-7509 +444 Hoes Lane Room RRC 1D-210 +Piscataway, NJ 08854 + + +From soh@andromeda.trl.OZ.AU (Kam Hung Soh) +Subject: Re: vi insert question +Date: Thu, 28 May 1992 22:02:42 GMT + +snk@fork.bae.bellcore.com (Samuel N Kamens) writes: + +>In article <1992May28.112017.21007@doug.cae.wisc.edu>, saunders@luther.che.wisc.edu (Brian E. Saunders) writes: +>> Say I have 1000 lines of text. Before each line, I want to insert a +>> specific character. How do I do this with 1 command? + +>:1,$s/^/c/ +> :1,$ (for every line in the file) +> s/^/c/ (replace the regular expression ^, which means +> "beginning of line", with the character c). + +``%'' is the abbreviation for ``1,$'' - the entire buffer. I.e: + +:%s/^/c/ + +This works for vi under SunOS and vim on the Amiga. For more vi +discussion, read comp.editors. + +Regards, + + +Soh, Kam Hung, Network Management Research, | h.soh@trl.oz.au +TRL, POB 249 Clayton, Victoria 3168, Australia | +61 3 253 6638 + + +From buck@pool.info.sunyit.edu (Jesse Buckley) +Subject: Re: vi insert question +Date: Thu, 28 May 1992 19:51:45 GMT + +In article <1992May28.112017.21007@doug.cae.wisc.edu> saunders@luther.che.wisc.edu (Brian E. Saunders) writes: +>Say I have 1000 lines of text. Before each line, I want to insert a +>specific character. How do I do this with 1 command? +> +>Note: each line before the character is inserted does not begin with the +>same character, so I can't do a simple substitution command. + +Actually you can. Try this... + +:1,$ s/^/XXXX/ + +It works on my system. (ULTRIX 4.2) + +-- +=) Buck (buck@sunyit.edu) +"I believe in getting into hot water; it keeps you clean." + -- G. K. Chesterton + + +From esaffle@gmuvax2.gmu.edu (L. Ron Hoover) +Subject: Re: vi insert question +Date: 29 May 92 03:07:13 GMT + +In article <1992May28.112017.21007@doug.cae.wisc.edu> saunders@luther.che.wisc.edu (Brian E. Saunders) writes: +>Say I have 1000 lines of text. Before each line, I want to insert a +>specific character. How do I do this with 1 command? +> +>Note: each line before the character is inserted does not begin with the +>same character, so I can't do a simple substitution command. + +if EVERY line has to have something inserted before it, meaning at the start +of every line, try this: + +:g/^/s//what you want inserted/ + +type it as show, substituting in the text you want instead of "what you want +inserted", of course. + +Ed + + +From agc@bnr.ca (Alan Carter) +Subject: Re: vi insert question +Date: Fri, 29 May 1992 09:40:48 GMT + +In article <1992May28.112017.21007@doug.cae.wisc.edu>, saunders@luther.che.wisc.edu (Brian E. Saunders) writes: +|> Say I have 1000 lines of text. Before each line, I want to insert a +|> specific character. How do I do this with 1 command? +|> +|> Note: each line before the character is inserted does not begin with the +|> same character, so I can't do a simple substitution command \ No newline at end of file blob - /dev/null blob + 4fe4f006ea9bee9a745afda9e935e46e160bc95f (mode 644) --- /dev/null +++ comp.editors/macrolimits @@ -0,0 +1,147 @@ +From jdawson@cs.utexas.edu (John Dawson) +Subject: Vi macro limitation +Date: 22 Jun 1992 01:51:21 -0500 +NNTP-Posting-Host: langtry.cs.utexas.edu + +I am trying to write moderately complicated vi macros and I'm bashing +my head against limitations whose nature I can't figure out. The +specific problem I was trying to solve is to whack some key, have vi +invoke make and send the output to a file, and edit that file; then, +use the normal motion keys/commands to move to a line that looks like + +FILENAME:LINENO:blahblah... # format of gcc + +and go to line number LINENO in file FILENAME. My original plan was +to move to the start of the line, and insert ":e ". Go to the next +colon, and insert a CR or ESC. Go to the next colon, and insert G. +Now the line should look like + +:e FILENAME:LINENOG:blahblah... + +Now the part that I can't do: go to the start of the line, and yank +the stuff up to the colon after FILENAME into one buffer, and yank +the "LINENOG" stuff into a second buffer. After this is all done, do +a U command to restore the line, and @-execute the buffers you just +yanked to. + +The problem is that whenever I try to do the yanking into a named +buffer, it gives my my favourite error, "Can't yank inside global/ +macro". I wasn't able to get it to yank anything at all +without it giving me that error, as I recall, but I tried doing the +"y" indirectly; i.e., I had a macro like + +map =y y + +and I would just do =y instead of y for the yank, and that pacified +the "Can't yank inside global/macro" message. But I wasn't able to +do this twice in one macro. (I tried many combinations of this +indirection, and they didn't help.) + +This is very baffling. Is someone else familiar with this problem? +If you want the macro I was using to generate this error, the yanking +part went something like this: (the insertion part isn't interesting) + +map =e 0"eyt:f:l"gyt: + +I don't have the original macro for this stuff; I've found a solution +that works using a single replacement to insert all the stuff on the +line, and then the yanking stuff WORKS! Here's that macro (I've taken +control characters and expanded them, sticking carets underneath them +to show where they are): + +map g mm:s/^\([^:][^:]*\):\([0-9][0-9]*\)/:e! \1^V^V^V^[:\2G/^M_ + ^ ^ ^ ^ ^ +map _ 0"e=yt:f:l"g=yt:u'm@e@g +map =y y +map =m :w!^M:!make -k >& ERRS^M:e ERRS^M + ^ ^ ^ + +The fact that the same yanking submacro works given a different +insertion technique is a great source of consternation. What is +the rule for when you can and cannot yank? Is there a workaround +for this? [Note: "Use Emacs instead!" is not a valid answer. A +good friend of mine, a self-proclaimed vi expert, gave me that +sage advice, along with a little lecture on how vi is an editor +and is Meant To Edit Text and isn't a kitchen sink like Emacs. +He should be ashamed of himself. Calling himself a vi guru, +indeed.] + +I can't help but think that this is possible to work around. After +all, I've seen gurus of ultimate godliness do things like Turing +machines and maze solvers with vi macros. + +-- +jdawson@cs.utexas.edu (John Dawson) + + +From jdawson@cs.utexas.edu (John Dawson) +Subject: Vi macro limitation +Date: 22 Jun 1992 01:51:21 -0500 +NNTP-Posting-Host: langtry.cs.utexas.edu + +I am trying to write moderately complicated vi macros and I'm bashing +my head against limitations whose nature I can't figure out. The +specific problem I was trying to solve is to whack some key, have vi +invoke make and send the output to a file, and edit that file; then, +use the normal motion keys/commands to move to a line that looks like + +FILENAME:LINENO:blahblah... # format of gcc + +and go to line number LINENO in file FILENAME. My original plan was +to move to the start of the line, and insert ":e ". Go to the next +colon, and insert a CR or ESC. Go to the next colon, and insert G. +Now the line should look like + +:e FILENAME:LINENOG:blahblah... + +Now the part that I can't do: go to the start of the line, and yank +the stuff up to the colon after FILENAME into one buffer, and yank +the "LINENOG" stuff into a second buffer. After this is all done, do +a U command to restore the line, and @-execute the buffers you just +yanked to. + +The problem is that whenever I try to do the yanking into a named +buffer, it gives my my favourite error, "Can't yank inside global/ +macro". I wasn't able to get it to yank anything at all +without it giving me that error, as I recall, but I tried doing the +"y" indirectly; i.e., I had a macro like + +map =y y + +and I would just do =y instead of y for the yank, and that pacified +the "Can't yank inside global/macro" message. But I wasn't able to +do this twice in one macro. (I tried many combinations of this +indirection, and they didn't help.) + +This is very baffling. Is someone else familiar with this problem? +If you want the macro I was using to generate this error, the yanking +part went something like this: (the insertion part isn't interesting) + +map =e 0"eyt:f:l"gyt: + +I don't have the original macro for this stuff; I've found a solution +that works using a single replacement to insert all the stuff on the +line, and then the yanking stuff WORKS! Here's that macro (I've taken +control characters and expanded them, sticking carets underneath them +to show where they are): + +map g mm:s/^\([^:][^:]*\):\([0-9][0-9]*\)/:e! \1^V^V^V^[:\2G/^M_ + ^ ^ ^ ^ ^ +map _ 0"e=yt:f:l"g=yt:u'm@e@g +map =y y +map =m :w!^M:!make -k >& ERRS^M:e ERRS^M + ^ ^ ^ + +The fact that the same yanking submacro works given a different +insertion technique is a great source of consternation. What is +the rule for when you can and cannot yank? Is there a workaround +for this? [Note: "Use Emacs instead!" is not a valid answer. A +good friend of mine, a self-proclaimed vi expert, gave me that +sage advice, along with a little lecture on how vi is an editor +and is Meant To Edit Text and isn't a kitchen sink like Emacs. +He should be ashamed of himself. Calling himself a vi guru, +indeed.] + +I can't help but think that this is possible to work around. After +all, I've seen gurus of ultimate godliness do things like Turing +machines and maze s \ No newline at end of file blob - /dev/null blob + b0476c9ba11cc58436ff502a9f63fba0b3ff1ea9 (mode 644) --- /dev/null +++ comp.editors/mapping @@ -0,0 +1,157 @@ +From saunders@luther.che.wisc.edu (Brian E. Saunders) +Subject: VI Mapping Help +Date: 11 Sep 92 18:24:32 CDT + +I am using remapping commands to do some common tasks in vi in a smaller +amount of time. If I place the map commands in the .exrc file, or the +.login file, these keyboard remappings work when I edit a file in my home +directory, but somehow they don't show up if I'm working in any +subdirectory. Can any of you gurus tell me why this is happenning? My +setting commands in the .exrc file and .login file (e.g. wrapmargin = n) +translate to the subdirectories, so this is very confusing behavior. +-- + +Brian E. Saunders saunders@luther.che.wisc.edu + + +From marak@alcor.concordia.ca ( Mike Marak) +Subject: Re: VI Mapping Help +Date: Sat, 12 Sep 1992 04:36:50 GMT + +In article <1992Sep11.182433.25903@doug.cae.wisc.edu> saunders@luther.che.wisc.edu (Brian E. Saunders) writes: +>I am using remapping commands to do some common tasks in vi in a smaller +>amount of time. If I place the map commands in the .exrc file, or the +>.login file, these keyboard remappings work when I edit a file in my home +>directory, but somehow they don't show up if I'm working in any + +One of the guys in the lab here showed us how to do this. Try this in your +.login: + + setenv EXINIT 'set wm=o [any other options] | source ~/.exrc' + +This works for ULTRIX (csh), abd should work for other flavors of unix. + + + Hope this helps + Mike + +****************************************************************** +* Mike Marak * mike@emc2.concordia.ca * * +* Lab Manager * (514)848-3118 * SPACE * +* EMC Lab * Room CC-109 * FOR * +* Loyola Campus * 7141 Sherbrooke St. W. * RENT * +* Concordia University * Montreal, Canada * * +****************************************************************** + + + +From tgtcmv@rwa.urc.tue.nl (Martien Verbruggen) +Subject: Re: VI Mapping Help +Date: 14 Sep 92 08:16:30 GMT +Reply-To: tgtcmv@urc.tue.nl + +saunders@luther.che.wisc.edu (Brian E. Saunders) writes: + +>I am using remapping commands to do some common tasks in vi in a smaller +>amount of time. If I place the map commands in the .exrc file, or the +>.login file, these keyboard remappings work when I edit a file in my home +>directory, but somehow they don't show up if I'm working in any +>subdirectory. Can any of you gurus tell me why this is happenning? My +>setting commands in the .exrc file and .login file (e.g. wrapmargin = n) +>translate to the subdirectories, so this is very confusing behavior. +>-- + +>Brian E. Saunders saunders@luther.che.wisc.edu + +Normally vi looks for a .exrc in the current directory first, then, if it +doesn't find one, in the directory that is contained by the environment +variable HOME (your home-directory), and then executes. +When you set the EXINIT variable, it will always execute the contents of this, +then look for a .exrc in the current dir, but it doesn't look in your home +directory anymore. (at least the vi versions I worked with didn't). +It took me a very long time to figure this out. Nowadays I don't set EXINIT, +but only keep a .exrc in my home and every other directory where it has to be +different (fortran, c, and so on). +This means that vi always uses the .exrc in my home, except when the current +directory contains one. + +Hope this helps. +-- +Martien Verbruggen (tgtcmv@chem.tue.nl) | + | If two wrongs don't make a right, +Eindhoven University of technology | try three. +Department of Chemical Engineering | + +From DSTEIS01@ulkyvm.louisville.edu (Donald S. Teiser) +Subject: map in .exrc versus via :map in vi itself +Date: Fri, 9 Jul 1993 14:32:30 GMT + +I have a question that is probably yet another vi FAQ: + +When I do the following in vi, it works for mapping "]" to "^D" + + :map ] ^V^D + +However, when I add the following line to my .exrc file, I end up with +the infamous "RHS missing" error when I :so .exrc + + map ] ^V^D + +I do not have this problem when mapping "[" to "^U". Any suggestions? + +********************************************************************* + ** Donald S. Teiser voice: (502) 588-7994 * + ** Tech Support for VMS & Ultrix fax: (502) 588-8896 * + ** University of Louisville Louisville, KY 40292 * + ** dsteis01@ulkyvm.louisville.edu * +********************************************************************* + + + +From Lowe@Fwva.Saic.Com +Subject: Vi mapping +Date: Wed, 21 Jul 1993 14:25:05 GMT + +Hi all. I have a problem. I created the following map in vi: +x j 4dd h dd k P h x d2w x J h r . 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 . 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 @@ -0,0 +1,277 @@ +From buboo@alf.uib.no (Ove Ruben R Olsen) +Subject: Re: mapping space bar +Date: Tue, 26 Jan 93 07:35:56 GMT + +Michael Doob writes: +>Is it possible to use the map command to remap the space bar? If so, what's +>the right syntax. Things like ^V 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 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 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 +>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 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 @@ -0,0 +1,125 @@ +From emm@daneel.rdt.monash.edu.au (Wendigo) +Subject: How to map! the tab character in VI +Date: 1 Jun 92 06:52:12 GMT + +How would one map the tab character in vi using the ":map!" command? + +Thanx +-- +Wendigo [ Occasionally thought of as |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + emm@daneel.rdt.monash.edu.au ] | "This isn't science fiction, + { Sometimes answers to Evan McLean } | this is StarTrek!" +(Now employed, no thanks to the government)| -- Shelia Willis + + +From sti@cs.hut.fi (Sami-Jaakko Tikka) +Subject: Re: Mapping 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 to +> and setting shiftwidth to your preferred indent. + +I believe the button producing right mix of tabs and spaces is + not 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 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! + +Some characters are special to vi and must be quoted. To quote, prefix +with 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 ^V^V^V^V^V^V + you see: map! ^V ^V^V^V + +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 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 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! + +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 @@ -0,0 +1,980 @@ +From spencer@lit.Princeton.EDU (S. Spencer Sun) +Subject: Re: A program to /* comment out */ automaticaly +Date: 22 Oct 92 03:50:26 GMT +Reply-To: spencer@phoenix.princeton.edu (S. Spencer Sun) + +This doesn't strike me as being a shell question so I've crossposted to +c.u.misc and directed followups there. + +In article , guy@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 + +This line in $HOME/.exrc will replace with whatever key (if +you want, say, ^A, you have to hit ^V^A to insert the actual control +character) and 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@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 + +>This line in $HOME/.exrc will replace with whatever key (if +>you want, say, ^A, you have to hit ^V^A to insert the actual control +>character) and 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 +#include +#include + +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 +#include +#include + +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 -- +| "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 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 so that +| I get +| +| joe +| pete +| ron +| mary +| rich +| nick +| ted +| +| I guess something of the form +| +| :1,$ s/, //g +| +| is what I am looking for. +| +| In general I guess I am looking for the representation for , +| , 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///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. " 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/'D"-+GAS1*>7+F#-KAFCY +M,16B5N7,$8IF8T>*<]S685/S)\HV8LR"2,-S:-"X36VBH1MF3-FSM$'@I5G9 +M8NG("7/5M$V<972R4#ER-LDQ@$^0C"U\#O&-%9O^A?.P[]_`T^=L')-R +M:$K.ALX`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#@PJL!J$9R4IZ:J5SU&@9$FJQ,=VHI9)4AK"35@B7 +M6W!]5-$8[&&)FQMUH%075$W$_A5=B"A^")I==4*Y=1(V8XVVSU +MS`XQI/767'S79&A3]AYQW8*56(TAQGH#TM3X7E'Y&/OE,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@PQD4-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;K3)(;D!,2YIP%0&)8SA@HM1-ZGNF; +M`-U#'S:0AG."`*`H$"A!^Z,YMA3T?.[QSAPC`%%(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 +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",\[&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@WX +MU4UE>TMFV]&.-[7W79,:^/MDY0ZXMR!@3+C`(*\1?T)9Y&!,GDR`V62A`;*K`,(:J!,.X#`!LJ$RPV4B0<0 +8X$"9(/'I_4H0-G +MI,2)(%-VO-A"`9DW=]RT""-'#LR43(PHJ`-G9LV;*L>\<4/')IL62Q2P*6.& +MCD^;=U(*)6JT!1(%.4)E204XN^._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!# +M00F*-+,,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,)^;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[$],0,<#&/$&5!17U8,6Q7T\X8B8NN+\K+BMQAF +M$Z)0)EQH7)<5T26L(6B154:T01S'946Z*>`)!VG4&V^P1VTE[%X*$(_KU&)$ +M'!026@G[%H['JHA-C+CG:QC"GM9CD#0QC.I`8UJ@46\Q>($(Q%.'VHC@AX.;`E^$M[=NG*)2VH'`K +MU1SA9*!1QDQA#!\%*4L+I]&;&H4-(M`H$X"SAJ"*0"YT*6JKLD>#%]0R#W`( +M"`A$T(.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)@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& +MBUM\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&O/2T'.DXWA"0D\='"3_&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)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%C0!EIX`)E$#I>X`6PX62&<1MNL(S,N"M%D&Y/=H'*\8N[ +MSo, 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 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 so that +> I get +> +> joe +> pete +> ron +> mary +> rich +> nick +> ted +> +>I guess something of the form +> +> :1,$ s/, //g +> +>is what I am looking for. +> +>In general I guess I am looking for the representation for , +>, 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 + 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 @@ -0,0 +1,180 @@ +From b.keck@trl.oz.au (Brian Keck) +Subject: modeline -> Modified +Date: Wed, 10 Jun 1992 04:59:34 GMT + +If I have even a trivial modeline, eg : + vi:map , j: +with a minimal .exrc : + set modeline +& no ~/.exrc or EXINITRC, +then when I start vi the file is immediately marked [Modified]. +This seems a bit repulsive. Is there a better fix than : + vi:map , j|w!: +Thanks, +Brian Keck +b.keck@trl.oz.au, phone +61 3 253 6407, fax +61 3 253 6362 +Network Services & Signalling, Telecom Research Laboratories +770 Blackburn Rd, Clayton Victoria 3168, Australia + + +From keck@wembley.trl.OZ.AU (Brian Keck) +Subject: Re: modeline -> Modified +Date: Thu, 11 Jun 1992 05:08:18 GMT + +I asked : + +>If I have even a trivial modeline, eg : +> vi:map , j: +>with a minimal .exrc : +> set modeline +>& no ~/.exrc or EXINITRC, +>then when I start vi the file is immediately marked [Modified]. +>This seems a bit repulsive. Is there a better fix than : +> vi:map , j|w!: + +I forgot to say this is SunOS 4.1.1 (:version -> Version SVR3.1) + +Thanks, +Brian KecFrom + +From: buboo@alf.uib.no (Ove Ruben R Olsen) +Subject: Re: how to set vi options in file to be edited? +Date: Tue, 26 May 92 21:50:34 GMT + +Lyndon C. Lim writes: + +>a friend told me once that vi used to be able to read +>either the first or last few lines of a file, in a +>certain format, and know that those lines were meant to +>be executed as vi commands. i haven't been able to +>find this in any documentation. i don't remember seeing +>it in the faq either. usually, i have ts=80, and sw=4. +>however, for certain files, such as shellscripts, i would +>like ts=4, sw=4. +> +>is this possible? i would prefer not to have local .exrc +>files since the directory also contains files for which +>i don't want ts changed. + +Well... in your $HOME/.exrc you must have + :set modeline +or else this will not work. +You may also set the $EXINIT to the appropriate. + +Taken from Marten Litmaath VI refference, Version 7: + + modeline | When you read an existing file into the buffer, + | and this option is set, the first and last 5 + | lines are checked for editing commands in the + | following form: + | + | vi:set options|map ...|ab ...|!...: + | + | Instead of a 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 @@ -0,0 +1,294 @@ +From jafo@miranda.accum.com (Sean Reifschneider) +Subject: Re: Editing multiple files in vi +Date: Thu, 24 Jun 1993 05:42:33 GMT + +In article 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 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 tma@encore.com (Thanh Ma) writes: + +>jafo@miranda.accum.com (Sean Reifschneider) writes: + +>>In article 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 tma@encore.com (Thanh Ma) writes: + +>>jafo@miranda.accum.com (Sean Reifschneider) writes: + +>>>In article 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 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 6, or possibly 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 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 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 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 @@ -0,0 +1,50 @@ +From hjiwa@gruc19.nor.chevron.com (Jeff Wang) +Subject: Re: nth occurance of a string +Date: 9 Jun 93 17:27:41 GMT + +gaspar@angelo.amd.com (Harand Gaspar) writes: +|> How does one find the nth occurance of a string or regualr expression +|> in a file using vi? + +Try this keymap :-) + +"? v - Find the nth occurrence of the pattern on the current line. +"? Enter pattern to search (can use regular expressions) on a new +"? line, then enter number (>1 but no more than 60 occurrences) +"? followed by \f in command mode to look for the pattern's nth +"? occurrence. nowrapscan must be set. If a mistake was made in +"? the pattern that was requested, u undo to bring back pattern. +map v I@x^[a^M^M/^[:mo---^M"xddf@imz`add`z^["yddma@yk + +where ^[ are quoted keys and ^M are quoted keys. + + Pressing the mapped key (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> 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 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>, 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 @@ -0,0 +1,66 @@ +From Tom Christiansen +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 @@ -0,0 +1,124 @@ +From kencham@myria.cs.umn.edu (Deepak "Kerd") +Subject: Could someone explain what "paragraphs=IPLPPPQPP LIpplpipnpb" means ?? +Date: 8 Jun 92 00:32:55 GMT +Article-I.D.: myria.kencham.707963575 + +Hi VI-GURUs, + +Just wondering what that setting means ..... Could you help me ? + +Deepak +-------------------------------------------------------------------------------- +Sherlock Holmes observed that ".. After you have eliminated the impossible, only +the possible, however improbable, remains..". I, however, do not like to elimin- +ate the impossible. And so I believe, Holmes and Watson were gays. +-------------------------------------------------------------------------------- +Email: kencham@{cs,centi.cs}.umn.edu Department of Gopher Science +Voicemail:(res)(612)339-8397 University of Minnesota + (off)(612)626-7524 Minneapolis, MN 55455, USA +-------------------------------------------------------------------------------- +-- +-------------------------------------------------------------------------------- +J.S.S.Holmes observed that ".. After you have eliminated the impossible, only +the possible, however improbable, remains..". I, however, do not like to elimin- +ate the impossible. And so I believe, Holmes and Watson were gays. + + +From nh@cbnewsg.cb.att.com (nicholas.hounsome) +Subject: Re: Could someone explain what "paragraphs=IPLPPPQPP LIpplpipnpb" means ?? +Date: Tue, 9 Jun 1992 07:25:00 GMT + +>From article , 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 @@ -0,0 +1,90 @@ +From larryhsu@mtl.mit.edu (Lawrence Hsu) +Subject: Paragraph wrapping in VI +Date: Fri, 29 May 1992 19:41:54 GMT + +Is there a relatively simple way of wrapping paragraphs in vi? +What I often want to do is wrap several short lines into fewer longer lines +without having to "J" them all together and then insert carriage returns. + +Many thanks, + +Larry Hsu +larryhsu@mtl.mit.edu + + +From hashmi@cse.uta.edu (Atiqullah Hashmi) +Subject: Re: Paragraph wrapping in VI +Date: Sat, 30 May 1992 23:41:07 GMT + +In article <1992May29.194154.18364@athena.mit.edu> larryhsu@mtl.mit.edu (Lawrence Hsu) writes: +>Is there a relatively simple way of wrapping paragraphs in vi? +>What I often want to do is wrap several short lines into fewer longer lines +>without having to "J" them all together and then insert carriage returns. + +Go to the first line of a paragraph and break that line where you +want the right margin. Then go to the starting of the first line(col. 1) +of that paragraph and do these things: + +press a '!' +press a ']' + Here your cursor will go to the bottom of screen and '!' will appear, then +type 'fmt' + +Note: Don't type any quotes as I have shown above, I used them for +clarity. Also, this method works for one paragraph only, so you will +have to do for each paragraph if you have more than one. + +Hope it helps + +hashmi + + +-- +--------------------------------- +Atiqullah Hashmi +UTA (Univ. of Texas at Arlington) +hashmi@cse.uta.edu + + +From dylan@ibmpcug.co.uk (Matthew Farwell) +Subject: Re: Paragraph wrapping in VI +Date: Sun, 31 May 1992 14:22:12 GMT + +In article <1992May30.234107.8048@cse.uta.edu> hashmi@cse.uta.edu (Atiqullah Hashmi) writes: +>In article <1992May29.194154.18364@athena.mit.edu> larryhsu@mtl.mit.edu (Lawrence Hsu) writes: +>>Is there a relatively simple way of wrapping paragraphs in vi? +>>What I often want to do is wrap several short lines into fewer longer lines +>>without having to "J" them all together and then insert carriage returns. +>Go to the first line of a paragraph and break that line where you +>want the right margin. Then go to the starting of the first line(col. 1) +>of that paragraph and do these things: +> +>press a '!' +>press a ']' + ^ +> Here your cursor will go to the bottom of screen and '!' will appear, then +>type 'fmt' + +Of course, he means '}' here. + +Dylan. +-- +It is no coincidence that in no known language does the phrase 'As +pretty as an Airport' appear -- Douglas Adams + + +From agc@bnr.ca (Alan Carter) +Subject: Re: Paragraph wrapping in VI +Date: 2 Jun 92 10:31:38 GMT + +In article <1992May29.194154.18364@athena.mit.edu>, larryhsu@mtl.mit.edu (Lawrence Hsu) writes: +|> Is there a relatively simple way of wrapping paragraphs in vi? +|> What I often want to do is wrap several short lines into fewer longer lines +|> without having to "J" them all together and then insert carriage returns. + +The vi command you need is + + :1,$!adjust + +The ! pumps the specified lines out to the standard in of the chosen program, +catches the standard out and replac \ No newline at end of file blob - /dev/null blob + 2d3c8ed2ae30bce13bc0fb23dbc67495afa680b2 (mode 644) --- /dev/null +++ comp.editors/readin @@ -0,0 +1,228 @@ +From jayers@hamline.edu (Judi Ayers) +Subject: VI editor questions +Date: 27 May 92 19:57:24 GMT + + +I have two files and this is what I'd like to accomplish: +While using vi on one file, I would like to read +in specific lines from a second file (I already know what the +line numbers are). Is there a way to do this using :r ? I know +I can write out specific line numbers to a file, and the command +I want seems to be one that is just the opposite. I've tried various +things with no luck and can't find any documentation on it. Any ideas? + +I hope this is the right group to ask about a VI question. If not, +I'm sure I'll hear about it. Or better yet, please direct me to the +correct group. Thanx. + +Judi Ayers +jayers@hamline.edu + + +From Tom Christiansen +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): += 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}' + +where startline and endline are the line numbers in 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 : +>:r !head -77 | 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 + | head - +OR + :r! sed -n ',p' + +The easy way to DO (You don't need exact line numbers--see NOTES): + + :e # edit second file + : # go to first line to copy + "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 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 @@ -0,0 +1,288 @@ +From sjreeves@eng.auburn.edu (Stan Reeves) +Subject: Regular Expression Question +Date: 12 Aug 92 12:54:06 GMT + + +I need to construct a regular expression that locates all words without +an "@". I've exhausted all my own ideas and was wondering if I could +draw on the expertise of this group. + + +-- +Stan Reeves +Auburn University, Department of Electrical Engineering, Auburn, AL 36849 +INTERNET: sjreeves@eng.auburn.edu + + +From lwv26@cas.org (Larry W. Virden) +Subject: Re: Regular Expression Question +Reply-To: lvirden@cas.org (Larry W. Virden) +Date: Thu, 13 Aug 1992 11:52:27 GMT + +In article sjreeves@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 @@ -0,0 +1,104 @@ +From watts@cs.scarolina.edu (Chris Watts) +Subject: VI: Repeating a command. +Date: 20 Jul 93 16:00:04 GMT + +Please tell there is a way in VI to do this! Let's say I want to move +lines 30 - 50 back 3 spaces. How would I do this. Or another question +is if I perform an operation on one line, how can I perform the same +operation on multiple lines. Thanks. + Chris Watts +------------------------------------------------------------------------------- +watts@cs.scarolina.edu + + +From lange@obelix.pcs.dec.com (Ralf Lange Digital-PCS GmbH) +Subject: Re: VI: Repeating a command. +Reply-To: lange@obelix.pcs.dec.com (Ralf Lange Digital-PCS GmbH) +Date: Wed, 21 Jul 1993 06:08:36 GMT + + +move back lines 30 - 50 3 spaces: +:30,50!expand +:30,50s/^ // + +the first command changes all tab characters to spaces. +The second command kills 3 spaces from the beginning +of every line. If your tab is set to three there is an +easier way: +type '30G' in command mode to goto line 30 and then '21<<' +to shift the current and the next 20 lines to the left. +An alternative would be: +:20,30<< + +to perform the same operation on multiple lines: + +this depends on what you did to change the first line. +If you used the substitute command, just give another +line range to perform the same substitution to other lines. + +EXAMPLE: +:s/.*/\L&/ + +changes the current line to lower case characters. + +Then +:20,50s +:'a,.s +:/Hi there/,$s +will do the same substitution from +line 20 to line 50 +mark 'a' up to the current line +the next occurence of 'Hi there' to the end of the file. + + + +From hansm@wsinti06.info.win.tue.nl (Hans Mulder) +Subject: Re: VI: Repeating a command. +Date: 21 Jul 1993 14:29:47 +0200 + +In watts@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 @@ -0,0 +1,21 @@ +From dattier@genesis.MCS.COM (DWT) +Subject: Re: Replacement prompting in vi? +Date: 7 Jun 1993 21:47:27 -0500 +Reply-To: dattier@genesis.mcs.com (DWT) + +thanasis@ucsb.edu (Athanassios S. Poulakidas) wrote in <8940@ucsbcsl.ucsb.edu>: + +| I'd like to have interactive search&replace in vi, i.e., when I want to +| substitute string1 with string2 globally, for each [occurrence] of string1 +| in the file, vi should ask me if the substitution should be performed. +| +| Is there a macro that efficiently does this? + +It's already built in. Add the c flag to the substitution command: + +:range s/target/replacement/gc + +David W. Tamkin Box 59297 Northtown Station, Illinois 60659-0297 +dattier@genesis.mcs.com CompuServe: 73720,1570 MCI Mail: 426-1818 + + blob - /dev/null blob + 0cd548dcaa786bb307046f4559769df8687654d2 (mode 644) --- /dev/null +++ comp.editors/sandr @@ -0,0 +1,94 @@ +From: dylan@ibmpcug.co.uk (Matthew Farwell) +Newsgroups: comp.editors +Subject: vi search and replace (LONG) +Keywords: vi replace +Date: 16 Sep 91 18:48:17 GMT +Reply-To: dylan@ibmpcug.CO.UK (Matthew Farwell) +Organization: The IBM PC User Group, UK. + +In article stanley@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: +:s/// + + 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. + + is just a normal regular expression [*] + 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 @@ -0,0 +1,186 @@ +From krisk@ux1.cso.uiuc.edu (Kris Klindworth) +Subject: Re: Is there a spellchecker for VI? +Date: Thu, 27 Aug 1992 15:49:15 GMT + +olsonkk@ucsu.Colorado.EDU (OLSON KIRK) writes: + + +>Hi all... I was wondering if anyone knew if a spellchecker for VI exists +>and or is available? Has anyone ever heard of such a thing? + +>Thanks! + +>Kirk +>-- +>Kirk Olson + +>olsonkk@ucsu.colorado.edu +>olsonkir@luther.uni.edu + + +If you're on a unix machine, you can pipe the lines to be +checked through unix spell. + +Ex. +:%!spell + +However, this must be undone immediately or you'll lose your +original text. An alternative way to do this is to save the file +and then run spell on it, reading the output into your current text file. + +Ex. +:w! +:0r !spell % + +This will put the misspelled words at the top of the file. + + +WHAT I DO: + +I use the following key mappings in my .exrc file to approximate +the word processor behavior of +automatically moving the cursor from one misspelled word to the next. + +map S :w!:0r !spell %:1,s/^/\//1G +map F "kyy@k + +Then a typical sequents is to hit S to run the spell checker, and load +the errors into the beginning of the file, hit F to load the word +into the find buffer, hit n to move on to the next occurrence of the word, +and dd when the cursor comes back to the first line of the file. + + +From siffert@spot.Colorado.EDU (Thunder-Thumbs) +Subject: Spell-check program needed for vi. +Date: Sat, 3 Jul 1993 20:28:53 GMT + +Is there any way, using vi (or a clone), I can put my cursor on +a word, hit a control-key sequence, and it will check the spelling +of that word, prompt me for a correct spelling, and correct it if +I so desire? + +I basically want the same functionality as ispell, but when I try +it with ispell, it always assumes the word is a file name and +buggers out on me. I haven't found a working flag. + +emacs has a M-x spell-word function, but I want it in vi. Any +ideas? + +Curt + + +From jansteen@cwi.nl (Jan van der Steen) +Subject: Re: Spell-check program needed for vi. +Date: 6 Jul 93 09:07:45 GMT + +siffert@spot.Colorado.EDU (Thunder-Thumbs) writes: + +>Is there any way, using vi (or a clone), I can put my cursor on +>a word, hit a control-key sequence, and it will check the spelling +>of that word, prompt me for a correct spelling, and correct it if +>I so desire? + +Try "spet", and a keymapping like: + + map q !!spet -v -t3^M + +This will spell the current line in verbose mode while ignoring +words with less than three characters in them. +Example: + + Let's say you wroote this and hit "q" + ^^^^^^ + +The program spet is available from: + + ftp : sun4nl.nluug.nl + dir : pub/textproc/txttools + file: spet-1.2.tar.Z + +Jan van der Steen +-- + -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- + Jan van der Steen jansteen@cwi.nl + Centre for Mathematics and Computer Science (CWI) + Kruislaan 413, 1098 SJ Amsterdam, The Netherlands + + +From msc@ssigate.ssinc.com (Michael S. Cross) +Subject: Re: Spell-check program needed for vi. +Date: Tue, 20 Jul 1993 12:32:04 GMT + + siffert@spot.Colorado.EDU (Thunder-Thumbs) writes: +>Is there any way, using vi (or a clone), I can put my cursor on +>a word, hit a control-key sequence, and it will check the spelling +>of that word, prompt me for a correct spelling, and correct it if +>I so desire? + +I don't know of any. + +>I basically want the same functionality as ispell, but when I try +>it with ispell, it always assumes the word is a file name and +>buggers out on me. I haven't found a working flag. + +vi is a text editor, not a word processor. Why don't you just finish +the "document" while the thoughts are still flowing, and run it through +ispell when you are through. ispell will *automaticly* replace the +misspelled words with your word of choice. + +Of course this doesn't always work so well with email or netnews postings. + +Hope it helps (tm). + +Mike + +-- +Michael S. Cross Work: msc%ssigate.UUCP@tellab5.tellabs.com 708-505-4508 + Home: 73750.1363@CompuServe.com (but not exactly *proud* of it) +Systems and Synchronous Inc., 900 E. Diehl Rd, Suite 110, Naperville, IL 60563 +__________________________To Live is to risk Dying____________________________ + + +From ray@Celestial.COM (Ray Jones) +Subject: Re: Spell-check program needed for vi. +Date: Thu, 22 Jul 1993 18:55:29 GMT + +In <1993Jul20.123204.8641@ssigate.ssinc.com> msc@ssigate.ssinc.com (Michael S. Cross) writes: + + +> siffert@spot.Colorado.EDU (Thunder-Thumbs) writes: +>>Is there any way, using vi (or a clone), I can put my cursor on +>>a word, hit a control-key sequence, and it will check the spelling +>>of that word, prompt me for a correct spelling, and correct it if +>>I so desire? + +>I don't know of any. + +>>I basically want the same functionality as ispell, but when I try +>>it with ispell, it always assumes the word is a file name and +>>buggers out on me. I haven't found a working flag. + +There are a couple of ways to do this. If you want to use ispell: +1. write the file to some tmp file +2. run ispell on the tmp file +3. replace the current doc with the correctly spelled tmp file. +that will spell check the whole document. +This can be done with the following map for function key 1 +map #1 :w %^M:!ispell %^M^M^[:0r % ^MjdG^M +There are a couple of extra keys in this but it does work. + +However, if you want put the cursor on a word, press Control-X and run +ispell on just that word and replace the word with the correct spelling, +then use the following map. + +map ^X i^M^[ea^M^[b:.w! /tmp/x^M:!ispell /tmp/x^Mbdw:r /tmp/x^MkkJJJ^M + +This map grabs the word, writes it to a file (/tmp/x), runs ispell on that +file, then replaces the word with the new contents of /tmp/x. If you are on +a multi-user system you may want to change the tmp file to something in your +home directory. This will leave tracks (/tmp/x and /tmp/x.bk) but they are +only one word long. + +-- +INTERNET: ray@Celestial.COM | The probability of one or more +Ray A. Jones; Celestial Software | spelling errors in this missive +8545 S.E. 68th Street | approaches unity. If this bothers you, +Mercer Island, WA 98040;(206) 236-1676 | run it through y \ No newline at end of file blob - /dev/null blob + 3663ee4869f07d63bd533c43ead8e8ffcec74d75 (mode 644) --- /dev/null +++ comp.editors/startup @@ -0,0 +1,861 @@ +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 +#include +#include + +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. ----------- + +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!" 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 +/ 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 +/ + +and have vi open with the cursor +at the first occurrence of . But +if I try to do this from within a shell +script it interprets +/ 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 +/ 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 +/ + + >and have vi open with the cursor + >at the first occurrence of . But + >if I try to do this from within a shell + >script it interprets +/ as a filename. + >Does anyone know how to run this from a + >script file? + +Put single quotes around the +/, 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 +/ 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 +/, 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 +/ 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 +/ 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 @@ -0,0 +1,194 @@ +From etxmesa@eos.ericsson.se (Michael Salmon) +Subject: Re: Q: Tab size in shell +Reply-To: etxmesa@eos.ericsson.se (Michael Salmon) +Date: Fri, 5 Jun 1992 08:53:11 GMT + +In article <1992Jun5.065506.27336@nuscc.nus.sg>, ccechk@nuscc.nus.sg (Heng Kek) writes: +|> How does one set the tab size for programs like 'cat', 'more' +|> etc? I edited a table using 'vi' whose tabstop setting is 2 +|> (i.e. tabstop=2). When I 'more' the file containing the table, +|> the format is screwed up because the tabs expand to 8 spaces or +|> something. +|> +|> I've gone thru the man pages for 'stty' and tried some stuff but +|> met with no success. Anyone know how to hack this? I'm on +|> ULTRIX 4.2 with vt100 term. +|> +|> Kek + +try piping your file through expand. + +-- + +Michael Salmon + +#include +#include +#include + +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 to control-T if they insist on hitting 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 +! + +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. + The character to be map!ped + +control-V Same. +control-V Similar. + What it is map!ped to. + +If you've done this and try to do again, you'll find that the gets +replaced by a (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. + +> 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. :-) + +>> 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 @@ -0,0 +1,91 @@ +From etxmesa@eos.ericsson.se (Michael Salmon) +Subject: Re: Q: Tab size in shell +Reply-To: etxmesa@eos.ericsson.se (Michael Salmon) +Date: Fri, 5 Jun 1992 08:53:11 GMT + +In article <1992Jun5.065506.27336@nuscc.nus.sg>, ccechk@nuscc.nus.sg (Heng Kek) writes: +|> How does one set the tab size for programs like 'cat', 'more' +|> etc? I edited a table using 'vi' whose tabstop setting is 2 +|> (i.e. tabstop=2). When I 'more' the file containing the table, +|> the format is screwed up because the tabs expand to 8 spaces or +|> something. +|> +|> I've gone thru the man pages for 'stty' and tried some stuff but +|> met with no success. Anyone know how to hack this? I'm on +|> ULTRIX 4.2 with vt100 term. +|> +|> Kek + +try piping your file through expand. + +-- + +Michael Salmon + +#include +#include +#include + +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 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 @@ -0,0 +1,33 @@ +From: wcs@ho95e.ATT.COM (#Bill.Stewart) +Subject: Re: Replacing tabs in vi +Date: 23 Jan 87 03:52:20 GMT +Reply-To: wcs@ho95e.UUCP (Bill Stewart 1-201-949-0705 ihnp4!ho95c!wcs HO 2G202) + +In article <3050001@hplsdlw.HP.COM> was@hplsdlw.UUCP writes: +>randy@tekla.UUCP (Randy Gibbons) asks: +>> Is there a way in vi to have spaces rather than tabs placed in the +>text. +>Unfortunately, vi has an annoying tendency to auto-indent using tabs. I +>don't know of a way to disable this (mis) feature. However, once the +>tabs are in the file, you can remove them [.......] +> ..... !Gcol -x (replace contents of file with detabbed output of col -x) + +(I happen to think tabs are a "good thing"; I'd much rather work in vi + where you get tabs too often than the rand editor which *always* + trashes tabs, even if they were in the original file. The usual + reasons for NOT wanting tabs are that you prefer non-equal tab + settings, or that you use other programs which don't default right.) + +To make vi not do tabs when you autoindent, do + :set tabstop=0 +This has the negative effect of displaying files with tabs in them a +bit weird (i.e. C programs.), but it means that vi will use spaces +instead of tabs to indent with. + If your real complaint is that you don't like tab stops of size +8, you can set ts=4 sw=4 and then print your programs using options to +expand tabs by +4 (e.g. pr -e4 foo.c) + +-- +# Bill Stewart, AT&T Bell Labs 2G-202, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs + + blob - /dev/null blob + 6c95444d32c99267d8ec4e24ecfdd7c5dfc77d54 (mode 644) --- /dev/null +++ comp.editors/termcap @@ -0,0 +1,327 @@ +From gerolima@Xenon.Stanford.EDU (Mark Gerolimatos) +Subject: Termcap/VI problem... +Date: Sun, 31 May 1992 21:00:20 GMT + +Try again.... + +I am adding in a new termcap entry for some bizarre terminal I bought. Works +fine, except that I can't get VI (and VI only) to take the termcap entry. +Keeps on complaining about unknown terminal types. + +Just to be safe, I took a similar termcap entry, copied, and renamed all the +name fields. Nope, VI still didn't take it. + +Any suggestions? + +-Mark +P.S. Please resond directly, if at all possible + +====================================Cut Here==================================== + + Mark Gerolimatos + +gerolima@xenon.stanford.edu "Righteousness comes ONLY from Jesus Christ... + @netlabs.com ...NEVER from an apron." + -Jack T. Chick + +================================================================================ + + +From gerolima@Xenon.Stanford.EDU (Mark Gerolimatos) +Subject: RE: Termcap/VI problem (got it, thanks) +Date: Mon, 1 Jun 1992 20:24:01 GMT + + +Oops, forgot to mention that I am running SunOS 4.1.1 + +Turns out that vi (as in /usr/UCB/vi) uses termINFO in SunOs. Why, +I'll never figure out. That was the problem. + +Thanx to all those who helped. +-Mark + +====================================Cut Here==================================== + + Mark Gerolimatos + +gerolima@xenon.stanford.edu "Righteousness comes ONLY from Jesus Christ... + @netlabs.com ...NEVER from an apron." + -Jack T. Chick + "La justicia viene so'lo por Jesucristo + ...NUNCA por un delantar." + -por Jack. T. Chick + +================================================================================ + + +From terry@npd.Novell.COM (Terry Lambert) +Subject: Re: Termcap/VI problem... +Date: 1 Jun 92 22:57:27 GMT + +In article <1992May31.210020.10270@CSD-NewsHost.Stanford.EDU> gerolima@Xenon.Stanford.EDU (Mark Gerolimatos) writes: +>Try again.... +> +>I am adding in a new termcap entry for some bizarre terminal I bought. Works +>fine, except that I can't get VI (and VI only) to take the termcap entry. +>Keeps on complaining about unknown terminal types. +> +>Just to be safe, I took a similar termcap entry, copied, and renamed all the +>name fields. Nope, VI still didn't take it. +> +>Any suggestions? + + It is nearly 100% likely that your vi uses TERMINFO, *not* TERMCAP +as the means of determining what escape sequences to use. This is true of +SunOS and most SysV binary distributions. + +How to find out from the csh: + + strings `which vi` | grep term + +You'll see a message similar to one of the following:: + + corrupted terminfo entry + terminfo entry too long + terminfo file for "%s" terminal is not readable + + +Ie: This vi was linked -ltermlib + +or something similar to: + + incomplete termcap entry + +Ie: this vi was linked with -ltermcap + + +To solve your problem if this is the case: + + Download 'captoinfo' from your friendly neighborhood archive, +compile it, and run it (alternately, you could learn to write terminfo +entries). + + If you can get a hold of a System V box that has the terminfo +of interest: + +To get a terminfo file from an already compiled terminfo database that +doesn't have the source around (SCO is famous for this): + + System V (at least) has a command called "infocmp" which will +dump an ASCII version of the compiled terminfo source for the terminal +currently referred to by the TERM environment variable. + + + + Terry Lambert + terry_lambert@gateway.novell.com + terry@icarus.weber.edu +-- +my present or previous employers. + + +From jpr@jpradley.jpr.com (Jean-Pierre Radley) +Subject: Re: Termcap/VI problem... +Date: Tue, 02 Jun 1992 03:56:15 GMT + +In article <1992May31.210020.10270@CSD-NewsHost.Stanford.EDU> gerolima@Xenon.Stanford.EDU (Mark Gerolimatos) writes: +>I am adding in a new termcap entry for some bizarre terminal I bought. Works +>fine, except that I can't get VI (and VI only) to take the termcap entry. +>Keeps on complaining about unknown terminal types. +>Just to be safe, I took a similar termcap entry, copied, and renamed all the +>name fields. Nope, VI still didn't take it. +>Any suggestions? + +I suggest that you provide your version of Unix when you post such a question. + +It is possible that your version of 'vi' knows nothing about termcap, and is +using terminfo instead. + +>P.S. Please resond directly, if at all possible + +You post here, you read here... + +>====================================Cut Here==================================== +> +> Mark Gerolimatos +> +>gerolima@xenon.stanford.edu "Righteousness comes ONLY from Jesus Christ... +> @netlabs.com ...NEVER from an apron." +> -Jack T. Chick +> +>================================================================================ + +Your signature is abusively long. Not its contents, its length. +Please recall that the news.* files suggest that 4 lines is sufficient for a +signature block. +-- +Jean-Pierre Radley Unix in NYC jpr@jpr.com jpradley!jpr CIS: 72160,1341 + + +From gert@greenie.gold.sub.org (Gert Doering) +Subject: Re: Termcap/VI problem... +Date: 2 Jun 92 14:26:35 GMT + +gerolima@Xenon.Stanford.EDU (Mark Gerolimatos) writes: + +>I am adding in a new termcap entry for some bizarre terminal I bought. Works +>fine, except that I can't get VI (and VI only) to take the termcap entry. +>Keeps on complaining about unknown terminal types. + +If you had told us what kind of Unix you are using, it would be easier to +answer... + +Nevertheless, on many unices VI uses not termcap but terminfo. + +gert +-- +Gert Doering | SubNet : gert@greenie.gold.sub.org | mailbox / uucp: +Munich / FRG | InterNet: gdoering@physik.tu-muenchen.de | call (089)3243328 +(089)3243228 | FidoNet : gert.doering@2:246/55.4 | login bbs / nuucp + + +From gert@greenie.gold.sub.org (Gert Doering) +Subject: Re: Termcap/VI problem (got it, thanks) +Date: 2 Jun 92 21:41:15 GMT + +gerolima@Xenon.Stanford.EDU (Mark Gerolimatos) writes: + +>Turns out that vi (as in /usr/UCB/vi) uses termINFO in SunOs. Why, +>I'll never figure out. That was the problem. + +Why? Because terminfo is far superior to termcap - more features, faster +access. + +gert +-- +Gert Doering | SubNet : gert@greenie.gold.sub.org | mailbox / uucp: +Munich / FRG | InterNet: gdoering@physik.tu-muenchen.de | call (089)3243328 +(089)3243228 | FidoNet : gert.doering@2:246/55.4 | login bbs / nuucp + + +From guy@Auspex.COM (Guy Harris) +Subject: Re: Termcap/VI problem (got it, thanks) +Date: 4 Jun 92 23:04:19 GMT + +>>Turns out that vi (as in /usr/UCB/vi) uses termINFO in SunOs. Why, +>>I'll never figure out. That was the problem. +> +>Why? Because terminfo is far superior to termcap - more features, faster +>access. + +It may be (although you'll probably find plenty of people who don't +think it's better; I'm pretty much neutral, so I'll let those people +jump into the fray - preferably in "comp.unix.questions"), but it +*wasn't* the reason. + +The reason was very simple: + +1) we wanted an 8-bit clean "vi" for SunOS 4.1, to handle character sets + such as ISO Latin #1; + +2) the SVR3.1 "vi" was already 8-bit clean; + +3) making the BSD "vi" 8-bit clean looked like a real chore; + +4) the SVR3.1 "vi" used "terminfo"; + +5) making the SVR3.1 "vi" use "termcap" looked like a real chore; + +6) "vi" is such a sewer that nobody particularly wanted to undertake + either of those chores; + +so we just dropped in the SVR3.1 "vi", with some changes to make it +build under SunOS's SV environment (which, in 4.1[.x], doesn't have +every single library or library routine from SVR3.1; the undocumented +"-lgen" was left out, as were AT&T's decidedly non-standard routines for +fetching character set information for the locale - we used the routines +from the ANSI C draft standard, instead). + +That also picked up a bunch of post-version-3.7 bug fixes, and various +other features such as "showmode"; "set showmode" puts an indicator on +the bottom line showing what mode you're in. + + +From terry@npd.Novell.COM (Terry Lambert) +Subject: Re: Termcap/VI problem (got it, thanks) +Date: Fri, 5 Jun 1992 17:53:07 GMT + +In article <1992Jun02.214115.11997@greenie.gold.sub.org> gert@greenie.gold.sub.org (Gert Doering) writes: +>gerolima@Xenon.Stanford.EDU (Mark Gerolimatos) writes: +> +>>Turns out that vi (as in /usr/UCB/vi) uses termINFO in SunOs. Why, +>>I'll never figure out. That was the problem. +> +>Why? Because terminfo is far superior to termcap - more features, faster +>access. + +Superior features like "we thought of everything, so you can't possibly need +to extend it, so we'll use a static structure for reading the file"? + +Faster access depends on how you set it up. It's perfectly acceptable to +have your TERMCAP environment variable contain your entire termcap string; +this means that it's already in your address space, automagically, when you +run your app. See 'tset' (UNIX) and 'resize' (X). + +If I want better than ISO (8 color) escape sequences, at least I have a way +to get them using termcap. + +The other drawback to terminfo is that if you don't have 'infocmp' and you +don't have terminfo source (many AT&T distributions left terminfo source +out), you have to write 'infocmp' or suffer with factory bugs. It's +relatively easy, on the other hand, to edit /etc/termcap. One glaring +use for this is to set "protect" to be reverse video on a Wyse-50, and +use it From gerolima@Xenon.Stanford.EDU (Mark Gerolimatos) +Subject: Termcap/VI problem... +Date: Sun, 31 May 1992 21:00:20 GMT + +Try again.... + +I am adding in a new termcap entry for some bizarre terminal I bought. Works +fine, except that I can't get VI (and VI only) to take the termcap entry. +Keeps on complaining about unknown terminal types. + +Just to be safe, I took a similar termcap entry, copied, and renamed all the +name fields. Nope, VI still didn't take it. + +Any suggestions? + +-Mark +P.S. Please resond directly, if at all possible + +====================================Cut Here==================================== + + Mark Gerolimatos + +gerolima@xenon.stanford.edu "Righteousness comes ONLY from Jesus Christ... + @netlabs.com ...NEVER from an apron." + -Jack T. Chick + +================================================================================ + + +From terry@npd.Novell.COM (Terry Lambert) +Subject: Re: Termcap/VI problem... +Date: Wed, 3 Jun 1992 16:37:22 GMT + +In article <1992Jun02.035615.5315@jpradley.jpr.com> jpr@jpradley.jpr.com (Jean-Pierre Radley) writes: +>In article <1992May31.210020.10270@CSD-NewsHost.Stanford.EDU> gerolima@Xenon.Stanford.EDU (Mark Gerolimatos) writes: +>>====================================Cut Here==================================== +>> +>> Mark Gerolimatos +>> +>>gerolima@xenon.stanford.edu "Righteousness comes ONLY from Jesus Christ... +>> @netlabs.com ...NEVER from an apron." +>> -Jack T. Chick +>> +>>================================================================================ +> +>Your signature is abusively long. Not its contents, its length. +>Please recall that the news.* files suggest that 4 lines is sufficient for a +>signature block. +>-- +>Jean-Pierre Radley Unix in NYC jpr@jpr.com jpradley!jpr CIS: 72160,1341 +====================================Cut Here==================================== +*****Mark Gerolimatos**gerolima@xenon.stanford.edu*"Righteousness comes ONLY fro +m Jesus Christ...**@netlabs.com***...NEVER from an apron."*******-Jack T. Chick* +* +==================== \ No newline at end of file blob - /dev/null blob + 47a1769a561618bd532893cc7a9374920db04174 (mode 644) --- /dev/null +++ comp.editors/toodanger @@ -0,0 +1,30 @@ +From fuenf@aldebaran.cs.uni-sb.de (Stefan Fuenfrocken) +Subject: "too dangerous to map that" +Date: 27 Jan 1993 09:05:45 GMT +PathPath: aldebaran!fuenf + +Hi, + +Under what circumstance do i get the " too dangerous to map that" message? + +There were a few times vi refused to map something. +e.g. perform search for fixed patten +:map xx /pattern + +Does this mean, that i probably will run into conflict with 'internal' vi mappings? + +Is there a way to do the mapping anyway. +e.g: space bar mapping (well, bad example, since it is not too dangerous to map ;) ) + +map ^V something + +an then redefine the mappings for 's' and '~', which use the spacebar-mapping, +accordingly with the 'l' as substitute. + + +Another question: + +-) is there a way to use the 'unmapped' meaning of mapped symbols? + suppose you map! the ESC-key to somthing (a stupid thing, i know ;) ), which + leaves you with (almost) no possibility to return from any insert/appand/open mode; + the only thing a can imagine, is to map! an other key to ESC ( with noremap \ No newline at end of file blob - /dev/null blob + 7a6dd99998a2c0906860aa5b04c91b25a97d573b (mode 644) --- /dev/null +++ comp.editors/toomuch @@ -0,0 +1,392 @@ +From tfoley@bnr.ca (Tristram Colville-Foley) +Subject: Still too much macro text! +Date: Mon, 06 Jul 1992 09:21:35 GMT + +I have been struggling to get round the now all too familiar `Too much +macro text' error message. I am sourcing the macros when I need them, +and not putting them in my .exrc, but after using them for a short period +of time, I get the above error message. Unmapping them doesn't work, but +if I can set up a macro to exit and then re-enter the file, now that +would be cool! Even better if I can come back to the place I was at. +How about a command echo the filename into a temporary file. Then I +could exit the vi session, read the temporary file and start up +another session. + +Any ideas? + +P.S. I have found that if you want to unmap a whole series of mappings +by sourcing a file, you must make the file look like this. + +unmap this| +unmap that| +unabbreviate this_as_well| <--- with the pipe symbol at the end, otherwise + you get silly errors like, + `That macro wasn't mapped' + +Sorry if this is obvious but it took several attempts and lots of head +banging before I figured it out. + + +From cameron@spectrum.cs.unsw.oz.au (Cameron Simpson) +Subject: Re: Too much macro text +Reply-To: cameron@spectrum.cs.unsw.oz.au (Cameron Simpson) +Date: Tue, 7 Jul 1992 09:57:36 GMT + +In article <1992Jul2.114727.24357@cas.org> lvirden@cas.org (Larry W. Virden) writes: +| In article <1992Jul1.134106.16089@news.eng.convex.com> tchrist@convex.COM (Tom Christiansen) writes: +| :From the keyboard of tfoley@bnr.ca (Tristram Colville-Foley): +| ::Any way I can get round this? +| : +| :Not easily. My bandaid solution was to re-compile vi with +| :a much larger buffer. I took the liberty of upping things +| :like line length and macro space by an order of magnitude. +| +| There IS one thing that you can try. Put your macros into some file +| OTHER than $HOME/.exrc . Do NOT source it in during $HOME/.exrc. Instead, +| source it in when you need it. + +And bypass macros as much as possible. My mail reader is a small Perl script +to update an index file and a set of vi macros. I append it as a shar file +later. + +Anyway, it sources on startup two files, which I list here: +The first file sets some catches for unused maps: + map \M !! + map Z + map \d + map \h + map \r + map \s + map \v +The second sets up the macros for perusing the index: + map \d :so .ex/index-d + map \h + map \r :so .ex/index-r + map \s + map \v :so .ex/index-v + " map + :so .ex/+ + +As much work as possible is done as ex-mode commands, reducing the macro text +(which I think maxes out at 128 characters on this system. Jeez.) + +| I suppose one thing one might do is add a bunch of unmaps to the beginning +| of the file so that you clear out previous macros before defining new ones - +| anyone know if that will reclaim space? + +I tried this: + - vi complains and aborts the command sequence if you unmap something + which wasn't mapped. Hence the first file shown above. + - there's a space leak of some kind. The unmaps don't get back nearly + enough. I gave them up. + - there's leaks in the remapping, too. Eventually my mail reader spins + out (harmlessly so far) and I have to leave and re-enter. Fortunately + this is pretty painless; it starts up fast. + +Peeves: + - vi aborts on an error. This is mostly ok, but it considers failed + searches an error. I may have to replace .ex/reply (below) with + something like + f reply + %!make-reply + This would be slower as it involves using another program. + - Worse! Vi (here, anyway) picks up next time in the middle of whatever + sequence it aborted. Totally weird. I suspect a local bug. + +Anyone know how to do conditional code in vi? + - Cameron Simpson + cameron@cs.unsw.oz.au + +#!/bin/sh +# + +mkdir cameron && cd cameron && mkdir .ex .pl bin || exit $? + +sed 's/^X//' > '.pl/updindex.pl' <<'EOF-//fuligin/1/cameron/etc/mail/.pl/updindex.pl' +X#!/usr/local/bin/perl +X# +X +X$cmd=$0; +X +X@INDEX=(); +Xundef %indexed; +Xif (open(INDEX,"< .index")) +X { while () +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 () +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 +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 @@ -0,0 +1,226 @@ +From david@cats.ucsc.edu (David Wright) +Subject: Re: Transferring lines between files in VI +Date: 8 Aug 92 03:56:57 GMT + + +In article <1683CE217.S947460@UMSLVMA.UMSL.EDU> S947460@UMSLVMA.UMSL.EDU writes: +|How can I transfer a few lines of text from one file to another +|using VI ? +|I tried yy , :e another file and then p, but it seems that +|yank/paste buffer is not preserved when I do this. + +This is an easy one. + +If you have set number on, you can give the command: + +:4,54 w>> otherfile + + +A more intuitive way is to yank into a named register. This will be +preserved when you + +:e otherfile + +you can put it when you get to that file. + +I use a macro that puts cut or pasted text into the register a, with the +command [ (Cut) or ] (delete). I then :e otherfile and use to put it: + +map "ap +map [ "ay'a +map ] "ad'a +-- + |^^^^^^| _______________________________________________________ + | | |"There is nothing in the marginal conditions that | + | | | distinguish a mountain from a mole hill" | + | (o)(o) O Kenneth Boulding | + @ _) o|_____________________________________________________| + | ____\ o o + | / + / \ All comments are mine---(David Wright) + + +From hc05@rexago8.uucp (Beirne Konarski) +Subject: Re: Transferring lines between files in VI +Date: Sat, 8 Aug 1992 12:32:36 GMT + +S947460@UMSLVMA.UMSL.EDU writes: + +>How can I transfer a few lines of text from one file to another +>using VI ? +>I tried yy , :e another file and then p, but it seems that +>yank/paste buffer is not preserved when I do this. + +Try + +"ayy +:e other-file +"ap + +The buffer holding the last action is cleared when a file is changed, but named +buffers are not. +-- +------------------------------------------------------------------------------- +Beirne Konarski | Reading maketh a full man, conference a +...uunet!rexago8!hc05 | ready man, and writing an exact man. +hc05%rexago8@uunet | -- Francis Bacon + + +From S947460@UMSLVMA.UMSL.EDU +Subject: Transferring lines between files in VI +Date: 7 Aug 92 21:04:38 GMT + +How can I transfer a few lines of text from one file to another +using VI ? +I tried yy , :e another file and then p, but it seems that +yank/paste buffer is not preserved when I do this. + + +From wyle@synopsys.com (Mitch Wyle) +Subject: Re: Transferring lines between files in VI +Date: 10 Aug 92 21:14:49 GMT + + +If you know that you want to copy all lines between parenthesis +or braces or brackets, you don't have to count lines; you +can use the % match command. + + +>Yanked text is not accessible across the files. But if you yank in the +>named registers, you can use them across the files. +> +>try, +> +>"a10yy : "a for using named register a, you can use a thr z registers, +> : and say you want to yank 10 lines, +> + +"ay% + +to grab the text. + + +If the entity is a paragraph, then + +"ay} + +will yank to the end of the paragraph boundary. + +It is almost never necessary to count lines. Getting in the habit of moving +and yanking using objects like sections, sentences, next close-parenthesis +etc. is useful. + + +>then goto the other file by +> +>:e other_file +> +>and +>put the yanked contents before a current line as +> +>"aP +> +>hope it helps, +> +>nitin + +>Nitin Kaulavkar, +>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, +Dept of Computer Scien \ No newline at end of file blob - /dev/null blob + 04a43574501f5313d73f88ae254fcc8eb47627ba (mode 644) --- /dev/null +++ comp.editors/undo @@ -0,0 +1,70 @@ +From: pgf@cayman.COM (Paul Fox) +Subject: Re: Undoing, Emacs and unlimited files ... summery. +Date: 27 Jul 92 19:51:02 GMT +Organization: Cayman Systems Inc., Cambridge Ma + +nmouawad@waterloo.edu (Naji Mouawad) writes: +: + ... a nice summary of undo strategies in various editors +: + +Gee, if I'd known everyone was going to be so informative, I'd have replied +to the original posting -- but better late than never: since it's just a +little different than the other method's described, here's how vile does +undo: + +(Note this is a vi-style "one command" undo, which undoes itself -- it is +not an "infinite" undo.) + +[ vile uses the linked list method of storage, with dynamically allocated +text blocks hanging off of each line "header". ] + +Undo operates by keeping a stack of "changed" lines (i.e. those affected +by a given command), along with information (more later) as to where they +should go if an undo is actually required. Thus if a character is deleted +on a line, a copy of the original line is pushed on the undo stack. If a +line is deleted, is simply moved to the undo stack. If a line is inserted, +a "tag" is pushed on the undo stack, which tells us where the corresponding +deletion should occur at undo time. Only the first change to a line causes a +copy to be stacked -- at that point, the line is flagged as having been +copied already, suppressing further copies. Since undo is itself undoable, +I found it easiest to keep two undo stacks -- when we do an undo, the +changes we are now undoing are simply put onto the alternate undo stack. +Multiple undo commands in a row simply cause us to move from one stack of +changes to the other (rebuilding the other each time). + +A certain amount of grottiness comes in because what we store as the +information needed to put the lines back in their place are actually +pointers to the lines in front and in back of its original location. Since +these pointers may be invalidated by subsequent changes during the same +command (if, say, the line following a changed line goes away altogether), +we need to store some pointer patches on the stack as weil, which, in +essence, say "when you pop this, go down through the stack and change all +instances of pointer A to pointer A', because that's its new value". I +didn't say it was beautiful. I would probably do things differently if I +were to do it now -- I knew _nothing_ about editors when I started +converting micro-Emacs to vile. + +One advantage of this stack approach is that it simply accumulates all +changes to a buffer until told to clean up the stacks. Thus it was trivial +to make global operations (:g/str1/s/str2/str3") and macros (like a set of +commands executed with '@a', or via the keyboard macro-recorder) undoable +all at once. The first case just worked, and for the second, I simply +delay the stack cleanup if a macro replay is in progress. + +Vi connosewers (sp? :-) will note that this is different than the stock vi +approach, in that it is totally independent of the default yank buffer. +That is, doing an undo will not affect the contents of the yank buffer. I +consider this a feature. + + +paul fox, pgf@cayman.com + + +(yes, it's available for ftp -- at ftp.cayman.com:/pub/vile) + +-- + paul fox, pgf@cayman.com, (617)494-1999 + Cayman Systems, 26 Landsdowne St., Cambridge, MA 02139 + + blob - /dev/null blob + 11e3e37d5b5b9a7a9071003d9b77800b8ec2ec9c (mode 644) --- /dev/null +++ comp.editors/vim @@ -0,0 +1,138 @@ +From alf.uib.no!trane.uninett.no!sunic!pipex!uunet!usc!sdd.hp.com!col.hp.com!csn!boulder!ucsu!spot.Colorado.EDU!siffert Thu Jul 15 18:23:34 MET DST 1993 +Article: 7246 of comp.editors +Newsgroups: comp.editors +Path: alf.uib.no!trane.uninett.no!sunic!pipex!uunet!usc!sdd.hp.com!col.hp.com!csn!boulder!ucsu!spot.Colorado.EDU!siffert +From: siffert@spot.Colorado.EDU (Thunder-Thumbs) +Subject: Re: VIM: Does it provide :ab[breviate] command ? +Message-ID: <1993Jul11.082004.9176@ucsu.Colorado.EDU> +Sender: news@ucsu.Colorado.EDU (USENET News System) +Nntp-Posting-Host: spot.colorado.edu +Organization: Thunder-Thumbs, Inc. +References: <1993Jul9.095130.8521@philce.ce.philips.nl> +Date: Sun, 11 Jul 1993 08:20:04 GMT +Lines: 23 + +i323856@indus.cad-sg.ce.philips.nl ( DEWENDRA SHASTRI ) scribes: +> +>Hi Netters, +>I am having a problem in switching from standarad vi to Vi iMitation (VIM) +>editor. I have lots of abbreaviations in .exrc file, vim cribs about them as +>"Invalid command". I did not find any referrence to this problem in the +>reference.doc supplied with the editor. Moreover differences.doc also +>doesnot talk about this. If any body has any information about this, it +>will be nice. +>Thanx in advans +>Devendra Shastri (i323856@cad-sg.ce.philips.nl) + +The abbreviate command counts as an Ex command, which isn't supported +fully in VIM. I got around this by remapping my abbr stuff to escape +key sequences. It's not a big deal. + +Incidentally, I didn't even realize that capability until recently. +In escape mode (both vi and vim), you can map something like esc-s +and it's a valid command if you do it fast enough. No wonder there's +that one-second lag before vi beeps at you on a double-escape... it's +making sure it's not a real command! pretty nifty. + +Curt (siffert@spot.colorado.edu) + + +From alf.uib.no!trane.uninett.no!sunic!uunet!news.cnri.reston.va.us!newsserver.jvnc.net!howland.reston.ans.net!math.ohio-state.edu!cs.utexas.edu!csc.ti.com!tilde.csc.ti.com!ra.csc.ti.com!process!frc Wed Jul 21 10:10:25 MET DST 1993 +Article: 7324 of comp.editors +Newsgroups: comp.editors +Path: alf.uib.no!trane.uninett.no!sunic!uunet!news.cnri.reston.va.us!newsserver.jvnc.net!howland.reston.ans.net!math.ohio-state.edu!cs.utexas.edu!csc.ti.com!tilde.csc.ti.com!ra.csc.ti.com!process!frc +From: frc@process (Robert Colon) +Subject: Re: VIM:Does it provide :ab[breviate] command ? +Message-ID: +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> +NNTP-Posting-Host: am.ucsc.edu + + +In 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 @@ -0,0 +1,419 @@ +From: jim@blade.stack.urc.tue.nl (Jim Rump) +Newsgroups: comp.unix.misc +Subject: Vi vs EMACS ans C-editing +Date: 23 Mar 92 21:51:08 GMT +Sender: news@tuegate.tue.nl +Organization: MCGV Stack, Eindhoven University of Technology, the Netherlands. +Lines: 408 +Status: RO + +Hello all, + +recently I posted something about wheter to use VI or EMACS for c-source +editing. This resulted in some interesting reactions. This is a summery. + +If you edit a lot of c-code then this is something for you to read. It +mostly gives objective opinios. + +(1) from: Rich + + I am someone who used to be a vi-head. I decided to bite the bullet and +learn emacs, and I love it. I actually use epoch which is an X windows +version of emacs. This is one advantage over vi. It is an X program +rather than an xterm running vi. + The main reason I learned emacs is because the choice of using emacs or +vi is not an either/or type of a choice. The real question is: + Do I want to know 2 editors or am I happy just knowing one? + + I decided that learning emacs was a good idea because then I would +would be more knowledgeable regardless of which editor I eventually decided +I liked better. I am better at my job because I know both vi +and emacs whereas all of the vi people only know vi. + + The main advantage of knowing both editors is that they each are better +for various things. I generally use vi for any quick edits I am going +to make. I also use it when I have to perform the same changes on a list +of files. The ":n" command works wonderfully for this. I generally use emacs +when I am sitting down and doing long coding sessions. One great thing +about emacs is that it buffers up all of your files and you can very easily +switch between several files. Another execellent feature is the undo +facility which will usually allow you to undo every single change to +a specific file 1 by 1. Emacs has several other great features but I +won't go into any more of them. + + In conclusion, you will never forget how to use vi, and you will +always need to use it for somethings. (ie. bringing up a new O.S. or +compiling emacs). The real question you should be asking yourself is +whether or not you want to learn a second editor. The question should never +be "emacs or vi?"; the question should always be "vi or (emacs and vi)?" +I believe that the answer to this question is obvious: the more you know, the +better off you are. You should realize that most emacs people know vi, whereas +the reverse is not true. I think this is because most people that have the +patience to learn emacs decide they like it better, and they don't switch +back to vi. + + -rich + +P.S. If you really do only want to know one editor, then I think the +choice has to be vi because this is what comes bundled with most +operating systems. + +****************************************************************************** +(2) from: ahcc!ebenv@uunet.UU.NET (eben) + + +I like vi. I used it for years, and my fingers can do anything in +their sleep, from editing multiple files to sorting a range to writing +a macro. + +So, when one day a colleague brought in a copy of emacs (this was +several years ago), I thought, "Great! Now we're going to have THREE +way religious wars!" (we had one vocal "j" user). + +Instead, miraculously, everyone switched to emacs. Even me, who had +sworn a life of love and allegiance to vi. + +I can still vi happily when need be. But when emacs is available, I +am more productive. I always have several shells around, have an +interactive sql session in a buffer, have lots of files in buffers, +and read and write mail in an integrated way. If you're stuck on an +antique dumb ascii terminal, rather than at a real terminal (an X +workstation), it gives you windowing, multiple shells, and many of the +things that are productive about a modern GUI. + +Over the 7 years since I met emacs, I've helped quite a few colleagues +to consider it. Without exception, they've stayed switched, and many +have come raving back to me months later wondering how they ever lived +without it. + +It's like unix--it's advantages over dos perhaps aren't visible in +your first day or week or month. But as you grow, you come to be more +productive and less frustrated. Good luck. + +-- +Eben + +****************************************************************************** +(3) from: James E. Leinweiber. + + +In the interests of avoiding yet another outbreak of the dreaded +editor flame wars (editor preferences are intensely personal, and all too +often dictated by whatever one learned first), allow me to offer the +following teaser document. I was trying to lure vi users to try +emacs, without much success, but we have only 3-4 programmers in my +organization, so I'm not heartbroken. Ignore all the references to +local customizations. I use both vi and emacs every day, learned vi +first, and greatly prefer emacs. Caveat Lector! + +James Leinweber State Laboratory of Hygiene/Univ. of Wisconsin-Madison +jiml@slh.wisc.edu uunet!uwvax!uwslh!jiml +1-608-262-0736 + +----------------------------------------------------------------------------- + + Emacs versus Vi + +Emacs is yet another text editor, which is older, larger and more +sophisticated than Vi. To learn to use it you should get a copy of the +quick reference guide and do the on-line tutorial. You may run the +tutorial by "emacs", 'backspace' 't'. In case of problems, abort +commands with '^G' and exit emacs by 'C-x' 'C-c'. (You may be asked +about saving buffers; just type 'n' or "no" 'RET' when you are +prompted for a response at the bottom of the screen.) + +Roughly speaking, Vi is superior for line-oriented editing, while +Emacs is better for other kinds of editing. For editing program text +it may be a toss-up, but Emacs can also edit odd files (binary, empty, +very long lines, ...) and is definitely superior for entering new +text. The main functional differences between Emacs and Vi are that +Emacs supports multiple window editing, horizontal scrolling, is fully +programmable, and has on-line help. However, only Vi will show line +numbers on the screen. (Vi is a screen interface to a line-oriented +editor; Emacs is not.) + +The feel of the two editors is very different. In Vi you are always +switching modes in order to give commands and enter text; in Emacs +text is self-inserting and commands are activated by a plethora of +control character sequences, using both the control and meta or Escape +keys. Vi has a larger repertoire of cursor motion commands, a handful +of operators, and short command sequences. Emacs relies more on +arguments to commands, and on applying commands to regions of text. +Many commands in Emacs are similar to using Vi commands with marks. + +Both editors understand indenting, filling, and abbreviating text, +although Emacs is better at these. Both allow named locations and +named buffers or registers for chunks of yanked or deleted text. Vi +is more convenient for some things, such as ":g/pattern/m$", which are +not directly built into Emacs. Emacs has nice commands such as "C-t" +to switch the last two characters, and "M-- M-c" to capitalize the +previous word. Undo is much better in Emacs, as are macros. + +For basic editing, using the two dozen or so most common commands, Vi +and Emacs are quite comparable in difficulty of learning and ease of +use. Since emacs has more concepts than Vi, about four times as many +commands, and a complete Lisp programming language built in, it is +significantly harder to master. Intermediate users may find that the +on-line help in Emacs outweighs the additional complexity. The extra +functionality in Emacs comes at a price: it plus its documentation use +large amounts of memory and disk, and it uses slightly more CPU time +than Vi. + + Learning Emacs + +The easiest way to learn emacs is just to type "emacs", and follow the +tutorial directions. After the tutorial you will know enought to +use emacs. Next you should study a quick reference card for about 20 +minutes, trying out some of the commands. Don't hesitate to use the +on-line help, and remember that you can undo mistakes regardless of +how many commands you have used in the meantime. It took me about a +week to get confortable using emacs and stop referring constantly to +the reference card, and it was worth it. Features of Emacs not found +in Vi and worth investigating include: windows, incremental search, +keyboard macros, recursive edits (particularly from query-replace), +narrow versus wide bounds, and shell mode. + + + Quirks + +Emacs expects to use C-g for interrupt, C-h for help, and DEL for +erase character, which conflicts with the standard SLH keyboard +conventions. You have three choices: live with the difference, give in +to emacs and put 'stty dec' in your .login file, or have me remap +your emacs keyboard (I use C-h for character erase, DEL for interrupt, +and C-g for help.). All three have annonying features, namely +cognitive dissonance, incompatibility with co-workers and the 1100, or +disagreements with the emacs manual. (E.g., references to C-x DEL +must be translated to C-X C-h). Start by trying plain emacs, and let +me know which you eventually decide on. + +The TAB key behaves unusually in Emacs: in indenting modes it restores +the indent of the current line, rather than inserting a TAB. In the +minibuffer it does command and filename completion, along with space +and CR. To insert one, use M-i or quote it (C-q C-i). + +Your emacs startup file is called ~/.emacs, and is written in Lisp. I +have provided a self-installing one to get things started. There are +a few differences from the documentation, which I will describe. + +First, the default mode is "indented-text" rather than "fundamental". +Furthermore, a comment character "#" is defined, so it should be very +easy to edit shell scripts. You can turn off the indenting with "M-x +text-mode RET". You can toggle auto-fill with "M-x auto-fill RET". +Mail mode will turn on auto-fill for you. C-mode will use the usual +Unix indenting style, rather than the default Gnu style. Personally, +I prefer the Gnu style (see /usr/src/local/screendump.c for an example). + +On an HDS terminal, the arrow, scroll and page keys will work, but not +on other types. As a side effect, the paragraph motion commands have +been moved from M-[ and M-] to M-{ and M-}. By the way, the Meta key +on the HDS terminals works; otherwise type M-{ etc. as "ESC {". On +other kinds of terminals, you will have to do this. + +Emacs prefers to run on terminals with flow control turned off, so +that C-s and C-q can be used as command characters. For this reason, +it uses alternate termcap entries that delay after slow operations. +Let me know if you have any problems with screen updating, as these +are usually caused by insufficient padding. + +CR and LF are changed: CR always indents and LF never does. Finally, +C-o (open-line) is modified to insert the current fill prefix. The fill +prefix is set by "C-x ." to the text before the cursor, and cancelled +by "C-a C-x ." (setting it at the beginning of a line). + +****************************************************************************** +(4) from : Glen Larsen + +I use both vi and emacs. If you're going to be on a u*ix system, +you're going to have to know vi. You can't beat it for quick edits +and those times that you aren't in your cozy little emacs environment. + +For me, emacs is a productivity tool for coding. It indents as I +write, I can change styles easily (or reformat somebody elses code so +I can view it the way I like it), and writing comments is a breeze. +Compilations are done with a single keystroke, if there are any errors +a single key sequence can get me to that line of code (and pull in the +file into another buffer if necessary). I can run shell commands on a +region or whole buffer. I have RCS commands bound to keys and the +dired (directory editing) mode so that I can check revisions out and +in (*and* write the commentary in an editor buffer). Also, I like +multi-buffer editing and writing lisp macros. + +Emacs is a different mindset. I'm sure your friends have shown you +how great emacs is, and what it can do that vi can't, you better be +prepared to hear that vi can do some things that emacs can't. Don't +let anyone tell you that it will make you a better software engineer. + +For me, vi has become another unix tool just like sed & awk --- great to +have around for those odd moments. Do what fits your style, but I +think you would be doing yourself a disservice if you don't learn +emacs sufficiently enough to see if it fits that style. + +- glen +-- +Glen Larsen glenl@hadar.fai.com +Fujitsu Network Transmission Systems (408)456-7890 +Software Technology Group, San Jose, CA, USA 95134 + + +(5) from: Jim Thompson + +I have been a unix programmer for the last four years, and for the first +three I used vi. I always had people telling me what a great editor +emacs was, and how I ought to be using it because it was so great. But +vi was doing the job just fine for me, and besides, every time I used +emacs, I couldn't figure out how to do *anything*, because of all those +complicated control sequences. + +When I started a new job about a year ago, I decided I would bite the +bullet, and learn emacs no matter how hard and frustrating it was. It +took me about a month to be able to use emacs effectively, and another +six or so before I was able to program lisp well enough to really +customize it. But it was well worth; I'm noticably more productive +using emacs than I was using vi. + +Your friends were right; for editing C code, emacs is fantastic--far +superior to vi. About the only support vi has for editing code are +auto-indent and the shift commands. Emacs, on the other hand, has a +"major mode" for editing C code, and it makes the job much easier. + +It's most effective when you're entering new code. As you type in the +code, emacs will automatically adjust the indentation levels to match +the nesting of the C control structures such as for-loops and if- +statements. Emacs will also automatically match paired characters for +you, such as (, ), {, }, [, ], to help cut down on syntax errors. + +Emacs is also better at entering long comments; it can automatically +break long comments and reindent them so they line up with the first +comment line. You just type the words, no matter how many; emacs does +the rest for you. Emacs also handles end-of-line comments well; you +can type M-; and the cursor will jump past the end of the line to a +predefined comment column and enter the comment-start characters. + +My best advice for you, should you choose to learn emacs, is to get a +book and read it first; it will help you greatly to know something about +emacs before you start trying to learn it. + +Good luck! +Jim +-- + _ Jim Thompson | Western Geophysical + | ~- thompson@wg2.waii.com | Exploration Products + \, _} jimt@sugar.neosoft.com | 3600 Briarpark + \( (713) 964-6213 | Houston, TX 77042 + + + +****************************************************************************** +(5) from: Gwyn Evans + + I find that GNU Emacs very useful for me when C coding as I like it's +options of auto-indent, auto-newline on ';','{' and '}'. All configurable +to match your required coding style, of course! + + I find that it's also very useful being able to have a number of files +open at the same time and to be able to have multiple windows on the screen. +It's best if you have a workstation :-) as you can have a large emacs +window but even on a tty, I find that I use vi for some quick edits but +for more than a couple of lines, I use emacs and then shell out of that +it I need to get to a cli. + + Another useful point is that it's got built-in help, which I found +very useful when starting. It also have a vi mode, although I don't +know if this has any ':' options as opposed to just the i,r,x,cw, etc +commands. + +Gwyn +-- ++======================================================================+ +| Gwyn Evans | evansg@uproar.enet.dec.com | Uxbridge, Middlesex, UK | +| DESISCo - Digital Equipment Service Industries Solutions Company Ltd | +| Views expressed and statements made are mine and not those of DEC | ++======================================================================+ + +****************************************************************************** +(6) from: Eric Wang + + +No contest. I was a vi power-user for two years, and find emacs to be +infinitely more powerful, especially for moderately large, nicely +modularized C (and Lisp and ksh) applications. In fact, I bet I can +make you switch with just one sentence: + +Emacs can edit multiple files on the screen simultaneously. vi can't. + +emacs will let you split your screen into 2 (or more) windows and look +at any 2 (or more) files simultaneously (or the same one in two places). +You can jump back and forth between windows. You can cut and paste +between them. They scroll separately. + +vi can maintain multiple files in memory, but it can display only one at +a time, and you MUST save or discard ALL your changes to it before vi +lets you switch to another one. + +I find that this one distinction between the two is one of the most +significant from a programmer's standpoint. If you have a moderately +large project of ~10 .c files and ~5 .h files, you will often want to +look at a .h file in one window while you edit a .c file in another +window. In emacs, this is EASY. In vi, it's IMPOSSIBLE. End of case! + +:-) + +(There are, of course, many more reasons to prefer emacs over vi. +Basically, whatever vi can do, emacs can do better. The *only* +advantage vi really has over emacs is that it's small, so it takes much +less memory and starts up more quickly. But then, the average tricycle +is smaller than the average car, too.) + +Eric Wang +wang@ibma0.cs.uiuc.edu + + +****************************************************************************** +(7)from: Nick Vargish + +I just switched to Emacs from vi myself... Emacs takes a while to get +used to (especially after vi), but you'll really like the difference. The +biggest selling point for me was that emacs is a mostly-modeless, +which means one moves, inserts, deletes, without having to switch +modes -- you know, like REAL text editors. + +vi is, after all, just a full-screen display grafted onto a line-based +editor. You'll see this more clearly if you try emacs for a couple of +days in your editing routine. + +Emacs can be daunting, but there are some good books out there on it, +and the time you invest in learning Emacs will be well rewarded... + + + + +-- +Nick Vargish +SURAnet Operations +vargish@sura.net + + +****************************************************************************** +(8)from: Linus Tolke + +What I believe is: +If you like to start an editor for every file then vi is *much* +faster. This is the only thing I find in favor of vi. + +Emacs is best used as an entire environment. You have all the files +you are editing within emacs, do the compilation within emacs, running +and debugging from within emacs. +-- + /Linus +***** Wherever I exec my `which emacs`, is my $HOME. ***** +Linus Tolke SM7OUU, linus@lysator.liu.se +Student at the member of SK5EU LiTHSA +Link|ping institute of technology, LiTH LiTH S{ndare Amat|rer (Ham-club) + +-- +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% Jim Rump % E-mail: % +% Eindhoven % jim@stack.urc.tue.nl % +% Netherlands % (TU-Eindhoven) % + + blob - /dev/null blob + b2ee7c54dfaec9b980eef4e292ac4d55d2db58d6 (mode 644) --- /dev/null +++ comp.editors/windowrez @@ -0,0 +1,33 @@ +From skf26@cas.org (Scott Frost) +Subject: Vi handling window resizing, how? +Date: Tue, 11 Aug 1992 11:59:44 GMT + +Currently, on my SunOS 4.2 version of VI, I have to do the following +after I resize a window in which vi is running to get it to recognize the +new window size, + + Qset term=xterm^Mvi^M + +I've tried mapping this to a macro, +but once the Q key is hit to leave VI, the rest of the macro is ignored. +Is there any way around this? + + +-- +Scott K. Frost UUCP: osu-cis!chemabs!skf26 +Same Mbox: BITNET: skf26@cas INET: skf26%cas.BITNET@CUNYVM.CUNY.Edu +Personal: 2753 Shrewsbury Rd, Upper Arlington Oh 43221 + + +From skf26@cas.org (Scott Frost) +Subject: Resizing VI - Trying again +Date: Fri, 14 Aug 1992 12:23:55 GMT + +Earlier I posted an inquiry about how to create a macro to perform the +following, + + Qset term=xterm^Mvi^M + +The vi on SUN 0S 4.1.2 does not recognize a window resize. Quitting vi, +resetting the term, and reinvoking vi works. The problem is that I can't +seem to map a macro to per \ No newline at end of file blob - /dev/null blob + 419af625798ab40b800b373cf7e9bc8ef2813a12 (mode 644) --- /dev/null +++ comp.editors/wordwrap @@ -0,0 +1,76 @@ +From stokesj@gordon-emh3.army.mil ( SFC John Stokes) +Subject: vi wordwrap +Date: 2 Jun 92 23:09:17 GMT + +Does any one have a suggestion as to how to rewrap a paragraph +in vi? Here is a line I have in my .exrc that does the current +line. Is there a way to extend this to continue down each line +until it gets to a blank line? One flaw in this definition is +the last word of the last line always wraps to the next line. + +map ^W J070lF r^M + +(Note I used the carot (^) symbol here to indicate Control +characters, which had to be quoted when entered.) + ______ + / + / __ /_ __ + ___/ /_/ / / / / Stokes + + +From damrau@sscux1.ssc.gov (Jackie Damrau) +Subject: Re: vi wordwrap +Date: Wed, 3 Jun 1992 13:20:37 GMT + +In article <30759@adm.brl.mil> stokesj@gordon-emh3.army.mil ( SFC John Stokes) writes: +>Does any one have a suggestion as to how to rewrap a paragraph +>in vi? Here is a line I have in my .exrc that does the current +>line. Is there a way to extend this to continue down each line +>until it gets to a blank line? One flaw in this definition is +>the last word of the last line always wraps to the next line. +> +>map ^W J070lF r^M +> +>(Note I used the carot (^) symbol here to indicate Control +>characters, which had to be quoted when entered.) +> ______ +> / +> / __ /_ __ +> ___/ /_/ / / / / Stokes + +To format a paragraph within vi, I have used: + +{!}fmt where "fmt" is the UNIX command that does what you want (e.g., +J). +-- +Jackie Damrau, SSC Laboratory +Computer Operations Group, MS-1011, +2550 Beckleymeade Avenue, Dallas TX +Internet: damrau@sscvx1.ssc.gov + +From tchrist@convex.COM (Tom Christiansen) +Subject: Re: vi wordwFrom mchinni@pica.army.mil (Michael J. Chinni, (SMCAR-CCS-W)) +Subject: Re: vi wordwrap +Date: 3 Jun 92 19:12:06 GMT + +John you wrote: +> Does any one have a suggestion as to how to rewrap a paragraph +> in vi? Here is a line I have in my .exrc that does the current +> line. Is there a way to extend this to continue down each line +> until it gets to a blank line? One flaw in this definition is +> the last word of the last line always wraps to the next line. +> map ^W J070lF r^M + +If your system has some BSD utilities, you can use "fmt". Quoting from the +"man" page for "fmt": +SYNOPSIS + fmt [ -width ] [ name ... ] + +DESCRIPTION + Fmt is a simple text formatter that reads the concatenation + of input files (or standard input if none are given) and + produces on standard output a version of its input with + lines as close to 72 characters long as possible. Default + line width can be altered with the -width option. The + spacing at the beginning of the input lines is preserved in + the ou \ No newline at end of file blob - /dev/null blob + 582305c6da6987990fb423d98b080a07c2770b29 (mode 644) --- /dev/null +++ comp.editors/writeout @@ -0,0 +1,92 @@ +From alex@am.sublink.org (Alex Martelli) +Subject: Re: Writing out a section of a file to another file with vi ??? +Date: 28 Sep 92 22:14:35 GMT + +mpalmer@encore.com (Mike Palmer) writes: + +:>What's the easiest way to write out a "block" of lines to another file, +:>without having to count the lines, or find the first line number and the +:>last? What I'd really like to do is dump a named buffer to disk: + +:>mx +:>y'x +:>write x to disk + +Once you have yanked to the *named* buffer, :e the file you want +to write it into, and just put it. NAMED buffers are remembered +by vi; it's only the UNNAMED one which is lost when switching files. +You will have to :w the current file before :e to the new one if +there were any changes (unless you :set autowrite, or are willing +to lose the changes). + +Alternatively, if you want to write to disk file pip from the +current line to mark x, just :.,'x w pip... + +I suggest that any followup be to comp.editors, as a more appropriate +newsgroup than comp.unix.anything would be. +-- +Alex Martelli - alex@am.sublink.org - +39 (51) 250434 - Bologna, Italia + + +From rouben@math9.math.umbc.edu (Rouben Rostamian) +Subject: Re: Writing a "block" of lines to another file +Date: Sat, 26 Sep 1992 12:41:44 GMT + +In article 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 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 @@ -0,0 +1,524 @@ +newsgroups: comp.editors,news.answers +Approved: news-answers-request@MIT.Edu +Followup-To: poster +Subject: comp.editors - List of editors +Expires: Sun 12 Sep 92 01:28:01 1992 GMT +Reply-To: Ruben@Uib.no + +Archive-name: editor-faq/Editor_List + +Version: Thu Aug 13 01:27:53 GMT 1992 + +Intorduction +^^^^^^^^^^^^ +This is a list of some of the editors availible on the net. + +This list is constantly updated. There will always be a updated +list on the VI/EX archives. + +I've restricted the various Emacs implementations to GNU emacs and +microemacs, because of Craig Finseth's posting on emacs implementations. + +Also, if I haven't listed an editor here that you want to find, then it +may be a good idea for you to look at the 'How to find sources' article +which is regularly posted to comp.sources.wanted, alt.sources and +news.answers. +And then when you find it, tell me about it. I would be exstremly happy +if you could submit the same information that the editors in this posting +have. + +I've tried to list at least ONE site in each part of the world (Europe, +North America, Australia and Asia). + + +Anonymous FTP +^^^^^^^^^^^^^ +To fetch a file from anomymous FTP do the following steps after beeing +connected to the FTP server: + - When the FTP server asks for a login, try either 'anonymous' or + 'ftp'. + - When the FTP server asks for a password, your password is the + same as your login-ID and your hostname. To enter this properly, + use the following format: + LoginID@HostName.DomainName. + DO NOT use 'ident' or 'guest' since this is bad nettiquette. + +If you are going to use FTP, use the site that is the closest to you +counting NET-VICE. If you don't know what I'm talking about, please +ask someone who know (ie. your system administrator). + +Why YOU shold use the site closest to you NET-VICE: + - Faster access. + - Reducing the net load. + - Keeping the site. + +Please do NOT use ftp to the sites during peak hours at the various +locations. Please respect this or else, if there is too much FTP'ing +going on prime time to the various places, the ftp site may have to +shut down. NON OF US WOULD WANT THAT, WOULD WE ? +So what is the peak hours at the various places in the world ? - Usualy +from 0800 AM to 0500 PM LOCAL TIME. + +Do absolutely NOT post a question to this news-group or other news-groups +questions about how to use FTP. Ask this question to your local system +administrator or at your local help desk. There is also a FAQ on how to +use FTP. Look for it in the news.answers newsgroups. + + +I need your help ! +^^^^^^^^^^^^^^^^^^^ +I have only access to UNIX, CMS, VMS and MSDOS computers. Therefore +editors from other machines and OS' will be exstremly limited unless +YOU help me out. + + +Editor writers +^^^^^^^^^^^^^^ +If you are a editor writer I would be happy to receive information about +your editor. What I want is: Editor name, Current release, Maintainer +(name and email adress), what OS the editor run's on. The editor's +file name (Example: fooBarEd.tar.Z) for easy searching with archie is a +must :-), either this or you include FTP sites where the editor is +sure to be found. A description of your editor should be limited to +15 lines of text. + + +Copyright +^^^^^^^^^ +This listing is copyright (C) Ove Ruben R Olsen. All rights reserved. + + +The listings +^^^^^^^^^^^^ +After a Anonymous FTP entry there is a date. This date is when the FAQ +maintainer last cheked the existance of the entry. +The date in the Current release, is the date when the maintainer got +the information about the upgrade or when the upgrade was announced on +NetNews. + +001) Ant's Editor. +002) ce +003) Crisp +004) Elvis +005) FPTED +006) GNU Emacs +007) JOE's editor. +008) Jstevie +009) Mutt Editor 2 +010) Microemacs +011) Mined +012) Origami +013) pico +014) REDT +015) Sedt Editor +016) SLIM +017) Stevie +018) TECO +019) TERSE +020) Vile + +------------------------------------------------------------------------------- +Editor: Ant's Editor. +Current Release: Anthony's Editor May 92 +Maintainer: Anthony Howe + +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 + +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 + +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 + +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 + +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 ] + + +-------------- +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: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 + +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 + +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 + +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 , "go to + line number" command , "set right margin" command + , "swap cursor and mark" command , "pump + block thru external filter" command , "exchange + marked block with paste buffer" command , "right + margin set" command 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 + +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 + +Anonymous FTP: + wsmr-simtel20.army.mil:PD1: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 + +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 @@ -0,0 +1,261 @@ +Newsgroups: comp.editors,news.answers +Approved: news-answers-request@MIT.Edu +Followup-To: comp.editors +Subject: comp.editors - Frequently Asked Questions +Expires: Fri 10 Sep 92 09:07:34 1992 GMT +Reply-To: Ruben@Uib.no + +Archive-name: editor-faq/The_FAQ + + + +The following file is a set of Frequently Asked Questions for the group +comp.editors. Certain questions get asked time and again, and this is +an attempt to reduce the bandwidth taken up by these posts and their +associated replies. If you have a question, please check this file +before you post. It may save a lot of peoples time. + +This FAQ tends to ignore emacs related questions, as they tend to be +answered adequately in the comp.emacs FAQ. + +Please send all comments, discussion, suggestions for new questions and +so on to me, Ove Ruben R Olsen . 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 +#include +#include +#include +#include + +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 @@ -0,0 +1,78 @@ +Newsgroups: comp.editors,news.answers,comp.answers +Followup-To: poster +Message-ID: +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 @@ -0,0 +1,43 @@ +Newsgroups: comp.editors +Subject: Not a regular request for vi-related files. +Followup-To: Poster +Reply-To: Ruben@Uib.no +Organization: University of Bergen, Norway +Keywords: vi-stuff, archives, anon ftp. +Summary: vi +Distribution: comp +Regularity: Whenever I feel for it. +BEWARE: mapping of ^D + +[To the comp.archives maintainers: Please do not archive this] + +This is a iregular request on EX/VI-related stuff for inclusion in the +VI-archives around the world. + +If you have stuff like tutorials, macros, tips, trics et.al about VI, +please mail them to Ruben@uib.no for inclusion in the VI-archives + +A index of the archives contents is posted in the end/begining of each +month to this newsgroup. + +And a thank you to all of you who have submitted information, macros et.al +to the archive. :-) + +VI/EX archives are to be found on the following anon ftp sites: + + alf.uib.no (129.177.30.3), PEEK: 0700 am GMT - 0300 pm GMT + utsun.s.u-tokyo.ac.jp (133.11.11.11) PEEK: 0100 am GMT - 0900 am GMT + cs.uwp.edu (131.210.1.4), PEEK: NONE + monu6.cc.monash.edu.au (130.194.1.106) PEAK: NOT RELEVENT + + +Please use the site wich is nearest your site net.vise. If you are not +sure of what I'm talking about, please ask someone who knows. This is +among others, your system manager. + +It's also possible to access the archives for those without ftp access. +Send a mail to Ruben@Uib.no with HELP as subject. + +Regards, +\Ruben + blob - /dev/null blob + 7a0a6b9761d87541d4dcbe74ca145d3f3911396f (mode 644) --- /dev/null +++ comp.editors3 @@ -0,0 +1,41 @@ +[... Old Article Quoting goes here ...] + + +From one of the INDEX files at the VI/EX archives around the world: + +[... Flielist ...] + +The VI/EX archives can be found at: + +Europe: + Main site: alf.uib.no (129.177.30.3) + Filearea: pub/vi + Peak hours: 07.00 am GMT to 03.00 pm GMT + +Japan: + Mirror site: utsun.s.u-tokyo.ac.jp (133.11.11.11) + Filearea: misc/vi-archive + Peak hours: 01.00 am GMT to 09.00 am GMT + +USA, Canada and Mexico: + Mirror site: cs.uwp.edu (131.210.1.4) + Filearea: /pub/vi + Peak hours: None. + + Mirror site: ftp.uu.net (192.48.96.9) + Filearea: /pub/text-processing/vi + Peak hours: None. + +Australia, NZ and the rest Down Under: + Main site: monu6.cc.monash.edu.au (130.194.1.106) + Filearea: /pub/Vi + Peak hours: Not relevent + + +For more information about the files in the archives fetch the INDEX file. + +If you need more information, you are welcome to mail Ruben@uib.no. + +\Ruben. + + 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 @@ -0,0 +1,121 @@ +From simonm@koel.mel.dit.CSIRO.AU (Simon McClenahan) +From: simonm@koel.mel.dit.CSIRO.AU (Simon McClenahan) +Newsgroups: comp.sys.sgi.bugs,comp.editors +Subject: Re: FAQ Alert: Mode Change for Pressing Arrow Keys in vi editor +Date: Tue, 14 Dec 93 03:58:28 GMT +Organization: CSIRO DIT (Melb.) +Lines: 39 + +In <1993Dec12.010048.23782@brl.mil> "RANDOLPH J. HERBER, HERBER@FNALA.FNAL.GOV, +1 708 840 2966, CD/HQ - CDF" writes: + +> > From: Jia-Yu Chiu +> +> > 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" writes: +> +>> > From: Jia-Yu Chiu +>> +>> > 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 @@ -0,0 +1,68 @@ +From prasad@cmie.ernet.in (Prasad Khurd) +Subject: Help ! - Converting Proper case to Upper case in Vi. +Date: Thu, 3 Jun 1993 11:51:58 GMT + +Hi there + + i read of a way to convert ALL upper case letters to lower case in the + file in VI in one shot (not using ~ which works per charater) on the + net somewhere but forgot it. i shall be very grateful if someone mails + me how to do that. + + thanx + Prasad Khurd. + +______________________________________________________________________________ +prasad@cmie.ernet.in +Centre for Monitoring Indian Economy, Bombay. +______________________________________________________________________________ + + +From edwin@integow.integrity.nl (Edwin Koedam) +Subject: Re: Help ! - Converting Proper case to Upper case in Vi. +Date: 4 Jun 93 06:52:47 GMT + +Prasad Khurd writes: +> Hi there +> +> i read of a way to convert ALL upper case letters to lower case in the +> file in VI in one shot (not using ~ which works per charater) on the +> net somewhere but forgot it. i shall be very grateful if someone mails +> me how to do that. +> + +You should use: + + :%s/./\u&/g + +Hope this helps, + +Edwin. +-- + UUCP: ..!uunet!mcsun!sun4nl!integow!edwin or INTERNET: edwin@integrity.nl + Edwin Koedam, software engineer, Integrity software consultants, + Pelmolenlaan 2, 3447 GW Woerden, The Netherlands. + tel +31 3480 30131, fax +31 3480 30182 + + +From edwin@integow.integrity.nl (Edwin Koedam) +Subject: Re: Help ! - Converting Proper case to Upper case in Vi. +Date: 4 Jun 93 06:54:19 GMT + +Prasad Khurd writes: +> Hi there +> +> i read of a way to convert ALL upper case letters to lower case in the +> file in VI in one shot (not using ~ which works per charater) on the +> net somewhere but forgot it. i shall be very grateful if someone mails +> me how to do that. + +Sorry, in my previous response, I converted all characters to uppercase. +To convert them to lower case, use: + + :%s/./\l&/g + +Edwin. +-- + UUCP: ..!uunet!mcsun!sun4nl!integow!edwin or INTERNET: edwin@integrity.nl + Edwin Koedam, s \ No newline at end of file blob - /dev/null blob + 3a9556b535db2f13e807d8dca117f826a39633b0 (mode 644) --- /dev/null +++ docs/casesr @@ -0,0 +1,39 @@ +From hansm@wsinti05.info.win.tue.nl (Hans Mulder) +From: hansm@wsinti05.info.win.tue.nl (Hans Mulder) +Newsgroups: comp.editors +Subject: Re: Changing case during search and replace in VI +Date: 14 Dec 1993 21:13:31 +0100 +Organization: Eindhoven University of Technology, The Netherlands +Lines: 30 + +In <2eh2q5$67i@ionews.io.org> chowwi@ionews.io.org (Wing-Chi Chow) writes: + +>Someone posted this awhile back, but I forgot to save the +>article :-(, so does anyone know how I can change +>the case of characters in a search and replace under VI. +>I think there were some commands like &U and &L. + +In the replacement string: + + \l changes the case of the next letter to lower case + \u changes the case of the next letter to lower case + \L changes case to lower case until \e or \E or end of replacement + \U changes case to upper case until \e or \E or end of replacement + + & denotes the string that matched the search pattern + ~ denotes the previous replacement string + + \1 denotes the string that matched the part of the search string + between the leftmost \( and the corresponding \) + \2 ditto for second \( + \3 ditto for third \( + : : : + : : : + +Thus :s/pattern/\U&/g changes all occurrences of "pattern" to upper case, + +-- +Hope this helps, + +HansM + 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 @@ -0,0 +1,7 @@ +"@pФadLA8nܙ¡:k@ +&aؔI sgAm(C& +7r15e9(evҀhf AS`  #G CG + 43aܤ357A-_w\dH%-UGǤuQ(n \ No newline at end of file blob - /dev/null blob + 50684dbb41df89a26c848a8b601bd8ec482f9898 (mode 644) --- /dev/null +++ macros/ruler.Z @@ -0,0 +1,4 @@ +"@Ǭr'8.9bJ7.