Return to BSD News archive
Xref: sserve comp.editors:12143 comp.unix.bsd:15972 Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!bunyip.cc.uq.oz.au!munnari.oz.au!uunet!usc!hookup!swrinde!howland.reston.ans.net!EU.net!sun4nl!news.nic.surfnet.nl!tuegate.tue.nl!news.win.tue.nl!news.win.tue.nl!not-for-mail From: hansm@wsinti05.win.tue.nl (Hans Mulder) Newsgroups: comp.editors,comp.unix.bsd Subject: Re: Obscure (to me, at least) bug in vi Date: 24 Jan 1995 16:35:51 +0100 Organization: Eindhoven University of Technology, The Netherlands Lines: 82 Distribution: inet Message-ID: <3g36on$t0c@wsinti05.win.tue.nl> References: <3f79vk$5c@darkstar.UCSC.EDU> <3g25g9$avc@griffin.itc.gu.edu.au> Reply-To: hansm@win.tue.nl NNTP-Posting-Host: wsinti05.info.win.tue.nl In article <3g25g9$avc@griffin.itc.gu.edu.au> Tony Nugent <T.Nugent@sct.gu.edu.au> writes: >I have a user who gets into those dark, cobwebby corners of vi. Here's a bug >he reported to me. >Make a .exrc file containing the line > map _ /-$(esc)JxX >where (esc) is the escape character. >Now try S to substitute something for the whole line. You'll find on >some versions of vi that the characters in the macro get stuck into the >line you are editing; specifically it will contain JxX- before you type >anything further. Then try Y to yank the whole line. Same thing happens. Then try :map _ k to confirm your worst fears: S behaves as if :mapped to c_ Y behaves as if :mapped to y_ C behaves as if :mapped to c$ s behaves as if :mapped to cl in some version; c<space> in others etc. In article <11034@dog.ee.lbl.gov> Chris Torek, at the time known as torek@ee.lbl.gov, currently known as torek@bsdi.com, explained: <In article <5108@lure.latrobe.edu.au> ECSGRT@lure.latrobe.edu.au <(GEOFFREY TOBIN, ELECTRONIC ENGINEERING) writes: <>Hold everything! Is Alexios accurate in stating that mapping <>a key [in vi] will change its INTERNAL usage? <This is correct. The list of such keys is: < <space> $ a i u \ _ r l <(this is for `Version 3.7, 6/7/85.'). <The reason is that vi implements a few commands by `pushing back' <some keys you never typed. For instance, typing `~' makes vi pretend <you typed r, <somechar>, <optional l>, where <somechar> is the <character under the cursor, with its case inverted if it is a letter, <and the <optional l> appears if there is a character after the cursor. <Thus, if you < :map l h <and type tilde in the middle of a line, vi will flip case and back up. <At the end of the line, vi will flip case and stay put. At the beginning <of a line, vi will flip case and beep at you. <This is just a symptom of a much greater underlying disease: vi's <internal design is a mess, largely because of the way vi was written. <Sometime in or around the 1970s, Bill Joy & co decided to extend the ed <editor; this became `ex' (the `extended' editor). Then they added <screen capabilities, invented termcap, added more stuff, ran out of <room on the PDP-11, chipped and hacked to fit, etc. At some point <Mark Horton took over development. Eventually he left; since then <there have been only minor changes at Berkeley (no one is doing any <`serious' development anymore). <There is, however, an external design, and vi works as it does not just <`because that was the way Bill Joy set it up'. For instance, the <original `delete line' command was `d_'; the original yank line command <was `y_'; and so forth. The concept of `stuttering' on a key came <later. The external design changes are part of the reason that the <internals are such a mess. In the vi I'm using (Version SVR3.1) tilde uses <optional space>, not <optional l> as Chris says. I hate that, since I'd like to map space to <control-F> for consistency with my pager program. Does anybody know in what versions of vi it is unwise to :map \ and what goes wrong if you do? Why are both space and <l> on the list of problematic characters? Surely, vi needs only one them? -- HansM