davidra@batcomputer.tn.cornell.edu (David A. Rabson) (06/24/88)
I was asked to make some vi macros to help some new users become adjusted
to UNIX (they wanted to emulate parts of their old editor) and found the
following bug:
The y (yank) command does not always do what is advertised. The following
will demonstrate the problem. In each case, begin with the cursor at the
beginning of the word "three" as shown below.
one two three four
^
command expected effect actual effect
------- --------------- -------------
"ay2fe puts `three' in buffer a; works as expected
does not move cursor
"aye should be exactly the same puts `thre' in buffer
as the first
emab"ay`a should be exactly the same puts `thre' in buffer
as the first two (note
that ` is accent-grave)
So it appears that when yanking with the `e' or ` command, one character fewer
than expected is actually grabbed. It turns out that exactly the same
problem afflicts the E,w, and W commands, but not the f command. I repeated
the problem on three different machines running 4.2 and 4.3.
It is a relief (and confirmation of my bug report) that if y (yank) is
replaced by d (delete) or c (change), there is no problem; everything
works as expected.
Now it would seem that adding a space (or l) after the e in the third
example would be a somewhat kludgy patch, but it still fails at the end
of a line.
Has this bug been reported previously?
David Rabson
davidra@helios.tn.cornell.edu
Laboratory of Atomic and Solid State Physics
Clark Hall, Cornell University
Ithaca, NY 14853-2501kevin@ttidca.TTI.COM (Kevin Carothers) (06/28/88)
In article 260 (David A. Rabson) writes: >So it appears that when yanking with the `e' or ` command, one character fewer >than expected is actually grabbed. It turns out that exactly the same >problem afflicts the E,w, and W commands, but not the f command. I repeated >the problem on three different machines running 4.2 and 4.3. [---other stuff---] >Now it would seem that adding a space (or l) after the e in the third >example would be a somewhat kludgy patch, but it still fails at the end >of a line. > >Has this bug been reported previously? > > David Rabson > davidra@helios.tn.cornell.edu > Laboratory of Atomic and Solid State Physics > Clark Hall, Cornell University > Ithaca, NY 14853-2501 I think that this was designed into vi because of some sort of logic concerning whether or not to append a new-line at the end of the text line. Vi has a rather fast (read "simple") screen painting algorithm that works on a rather vast array of different terminal types. Personally I can't imagine trying to build a "generic" editor that switches with relative ease between terminals that have line/page scrolling, wrap/nowrap, advanced/no cursor positioning, etc... Support for just about any terminal made is a *REALLY NICE* feature of vi that I haven't seen too many editors do to the degree that vi has. It would be easy enough to make a "vi-like" editor that really hums on a VT-100 or the like, but might be limited on the other terminals vi runs on. _ , __ ' ) / / ) _/_ / /-< _ , __o ____ / __. __ ____/ /_ _ __ _ / ) </_\/ <__/ / <_ (__/ (_/|_/ (_(_) (__/ /_</_/ (_/_)_ ========================================================================= The Name: Kevin Carothers !{csun,psivax,rdlvax,trwrb}!ttidca!kevin The Place: Citicorp/Transaction Technologies The Biz: Consumer & Commercial banking systems The Quote: "What this country needs is a good 5 dollar plasma weapon." -The Military Industrial Complex