*BSD News Article 41539


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