[comp.editors] tough bug in vi

phil@uxh.cso.uiuc.edu (11/21/88)

Calling all vi hacks:

When I tried to learn to use vi I ran into one bug that effectively makes
vi useless to me.  I showed it to several people who, once they saw what it
was, said that it could not be fixed.  One person suggesting modifying the
source.  I went back to Emacs instead.

This bug works like this:

I go into insert mode with "i" and type in some new text.  I then backspace
over that text with ^H (backspace).  The text is no longer in the buffer
but is still showing on the screen.  To me this is a serious bug because
I frequently make mistakes and go back and correct them.  I get totally
out of whack when I have to work in the blind, or exit insert mode just
to see what I am doing (and go back in it again).

So, is there anyone out there that knows how to fix this so I can go back
to learning how to use vi?

malpass@vlsi.ll.mit.edu (Don Malpass) (11/24/88)

In article <11500001@uxh.cso.uiuc.edu> phil@uxh.cso.uiuc.edu writes:
>I go into insert mode with "i" and type in some new text.  I then backspace
>over that text with ^H (backspace).  The text is no longer in the buffer
>but is still showing on the screen.

I am sure I've seen this, but I think on some machines I've also NOT
seen it.  Therefore there's some chance it may be a termcap file
definition problem.  Since it doesn't bug me as much as it does you,
the details don't stick in my mind.  I'll try to take note of how
vi deletions act in the other machines I use, and if there's anything
of interest I'll pass it on.  Meanwhile, the pointer to termcap
may prompt some guru to contribute some wisdom if that's the trouble.
-- 
Don Malpass   [malpass@LL-vlsi.arpa],  [malpass@gandalf.ll.mit.edu] 
  The Malpass Principle:  Given a binary choice, the statistical
    probability of doing the right thing is 31.7% - on good days.

les@chinet.chi.il.us (Leslie Mikesell) (11/24/88)

In article <11500001@uxh.cso.uiuc.edu> phil@uxh.cso.uiuc.edu writes:

>I go into insert mode with "i" and type in some new text.  I then backspace
>over that text with ^H (backspace).  The text is no longer in the buffer
>but is still showing on the screen.  To me this is a serious bug because
>I frequently make mistakes and go back and correct them.  I get totally
>out of whack when I have to work in the blind, or exit insert mode just
>to see what I am doing (and go back in it again).

I guess I have just gotten used to this behaviour - thinking back to when
I first used vi, it bothered me too.  However, it is only a problem when
inserting into an existing line, since when you are inserting into an
empty line you know that there is no "real" text past the cursor position.
Anyway, ESC i will fix everything and is safe to do anytime you want to
be in insert mode.

The real solution is to learn to use the other vi commands and avoid
backspacing beyond the character or word that your cursor is on.  For
example, if you are several words past the one you want to correct it
might be faster to postion back with a search, then use cw to change
it, followed by A to get back to the end of the line.  This also has
the advantage of being repeatable if the word needs to be changed
elsewhere.

Les Mikesell

kolding@june.cs.washington.edu (Eric Koldinger) (11/24/88)

In article <11500001@uxh.cso.uiuc.edu> phil@uxh.cso.uiuc.edu writes:
>
>I go into insert mode with "i" and type in some new text.  I then backspace
>over that text with ^H (backspace).  The text is no longer in the buffer
>but is still showing on the screen.

This isn't a bug, it's just the way 'vi' works.  'vi' is optimized to keep
traffic over lines to a minimum, so it's actually a good feature for those
of us who use slow telephone lines and dumb terminals to communicate.

-- 
	_   /|				Eric Koldinger
	\`o_O'				University of Washington
  	  ( )     "Gag Ack Barf"	Department of Computer Science
       	   U				kolding@cs.washington.edu

msf@prandtl.nas.nasa.gov (Michael S. Fischbein) (11/24/88)

I tried sending a mail reply, but it bounced.

Try the command :map! ^H ^? ^?

where ^H means backspace, and ^? means delete.  Note that these can't be
entered directly, but must be quoted with control-V.  To automate them,
put the command in your .exrc or EXINIT.

		mike

Michael Fischbein                 msf@prandtl.nas.nasa.gov
                                  ...!seismo!decuac!csmunix!icase!msf
These are my opinions and not necessarily official views of any
organization.

aho@cory.Berkeley.EDU (Alex Ho) (11/24/88)

In article <11500001@uxh.cso.uiuc.edu> phil@uxh.cso.uiuc.edu writes:
>
>This bug works like this:
>
>I go into insert mode with "i" and type in some new text.  I then backspace
>over that text with ^H (backspace).  The text is no longer in the buffer
>but is still showing on the screen. 

i believe that vi does this so that one can still use the program
when working from a slow dumb terminal (at something like 300 baud).

to refresh the screen, you can type either ctrl-l or ctrl-r and the
screen should refresh.

alex.


Alex Ho                                  
University of California, Berkeley       aho@cory.berkeley.edu
                                         ...ucbvax!cory!aho

gwc@root.co.uk (Geoff Clare) (11/24/88)

In article <11500001@uxh.cso.uiuc.edu> phil@uxh.cso.uiuc.edu writes:
>I go into insert mode with "i" and type in some new text.  I then backspace
>over that text with ^H (backspace).  The text is no longer in the buffer
>but is still showing on the screen.  To me this is a serious bug because
>I frequently make mistakes and go back and correct them.  I get totally
>out of whack when I have to work in the blind, or exit insert mode just
>to see what I am doing (and go back in it again).

I haven't seen an answer to this, so I'm posting my suggestion in case
it is of use to others.

If you could get used to using DELETE instead of BACKSPACE you could
map DELETE onto the sequence BACKSPACE-SPACE-BACKSPACE so that the
characters are erased on the screen.  I have tried this and it works well.
(If you use DELETE as your interrupt character, you will need to change
it to something else, like CTRL-C, using stty in your .profile/.login).

To set it up put the line:

	map! ^? ^H ^H

in your .exrc file.  (To enter the text after the 'map! ' you need to type
CTRL-V DELETE SPACE CTRL-V BACKSPACE SPACE CTRL-V BACKSPACE).

You might also want to use the following mapping so that you can use
DELETE in command mode to delete the character to the left.

	map ^? X

Hope this helps.
-- 

Geoff Clare    UniSoft Limited, Saunderson House, Hayne Street, London EC1A 9HH
gwc@root.co.uk   ...!mcvax!ukc!root44!gwc   +44-1-606-7799  FAX: +44-1-726-2750

bengsig@orcenl.uucp (Bjorn Engsig) (11/24/88)

In article <11500001@uxh.cso.uiuc.edu>, phil@uxh.cso.uiuc.edu writes:
> 
> I go into insert mode with "i" and type in some new text.  I then backspace
> over that text with ^H (backspace).  The text is no longer in the buffer
> but is still showing on the screen.

You can use a map! <key> ^H ^H, where a good choise for key could be
DEL, if this is not your interupt.  Else find some other key that is available.
The map! command is used to change the function of a key in insert mode,
and the <backspace> <space> <backspace> will provide you with exactly what
you want.  If you put the map! in your .exrc, remember that you can only enter
^H (and possibly the <key>) by preceeding it with ^V.
-- 
Bjorn Engsig, ORACLE Europe      \ /    "Hofstaedter's Law:  It always takes
 ..!uunet!mcvax!orcenl!bengsig    X      longer than you expect, even if you
phone:  +31 21 59 56 411         / \     take into account Hofstaedter's Law"

pjh@mccc.UUCP (Pete Holsberg) (11/25/88)

Won't ^L repaint the screen so that it matches the buffer's contents?


-- 
Pete Holsberg                   UUCP: {...!rutgers!}princeton!mccc!pjh
Mercer College			CompuServe: 70240,334
1200 Old Trenton Road           GEnie: PJHOLSBERG
Trenton, NJ 08690               Voice: 1-609-586-4800

wyle@solaris.UUCP (Mitchell Wyle) (11/27/88)

Map the ^H char to be delete, insert as in:

map! ^V^H ^V^?i


-- 
-Mitchell F. Wyle                         wyle@ethz.uucp
Institut fuer Informatik                  wyle@inf.ethz.ch
ETH Zentrum / 8092 Zurich, Switzerland    +41 1 256 5237

les@chinet.chi.il.us (Leslie Mikesell) (11/30/88)

In article <492@solaris.UUCP> wyle@ethz.UUCP (Mitchell Wyle) writes:
>Map the ^H char to be delete, insert as in:
>map! ^V^H ^V^?i

Doesn't work here.  If you happen to have done an "stty erase '^?'" it
does at least delete a character, but it leaves you in a different place
depending on whether you were at the end of a line or not.  I think that
you really need <esc>xa if you are at the end of a line, <esc>xi otherwise.
Anyone else have a solution?

Les Mikesell

kevin@stl.stc.co.uk (Kevin Lewis) (12/01/88)

In article <7032@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes:
>In article <492@solaris.UUCP> wyle@ethz.UUCP (Mitchell Wyle) writes:
>>Map the ^H char to be delete, insert as in:
>>map! ^V^H ^V^?i
>
>Doesn't work here.  If you happen to have done an "stty erase '^?'" it
>does at least delete a character, but it leaves you in a different place
>depending on whether you were at the end of a line or not.  I think that
>you really need <esc>xa if you are at the end of a line, <esc>xi otherwise.

The real problem here is that once you come out of the current insert or append,
and enter another one, you can't delete past the beginning of the insertion.
This means that you can only delete on character at a time, but you can 
continue inserting. Any answers out there? Myself, I'm happy with mapping
delete to ^H ^H, as I don't mind the text not moving backwards.

kev


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Lewis 				STC Technology Ltd
+44 279 29531 ext 2579			London Rd 
Email: kevin@stl.stc.co.uk     	        Harlow   CM17 9NA
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

olsen@amelia.nas.nasa.gov (Michael E. Olsen) (12/10/88)

In article <11500001@uxh.cso.uiuc.edu> phil@uxh.cso.uiuc.edu writes:
>
>Calling all vi hacks:
>
>This bug works like this:
>I go into insert mode with "i" and type in some new text.  I then backspace
>over that text with ^H (backspace).  The text is no longer in the buffer
>but is still showing on the screen. 

This is my favorite editor, and I have seen various incantations of it in
my travels.  The mapping tricks to get destructive backspace are fine if
they work, but I believe the "elegant" solution is to 
:se redraw
which will either do nothing at all (most versions of the editor) or will
(and I quote) "simulate a smart terminal".  I think this feature is usually
made to do nothing so that (as others have noted) the editor transmits
as few characters as possible.  

On some of the UNIX systems I have seen a version of vi which is invoked 
as "vedit", let you know when you're in insert mode, etc. with prompts 
at the bottom of the screen.  If you're learning, or if you have a limited
memory for editor fine points like I do, I heartily suggest you obtain a
vi "cheat sheet" (mine is titled Ex Quick Reference of course).  I have
used the editor for a while now, and I still am amazed at all the features
I can forget in between perusals of this sheet.

phil@uxg.cso.uiuc.edu (12/21/88)

Thanks for all the posting and e-mail about vi.  The responses varied over
quite a wide range from "it works as designed" to "here's how to fix it".
Sorry I haven't had time to actually try out any suggestions.  I might
have that time in the next couple of weeks (hopefully).

Consider an editor environment (not necessarily emacs) where something is
mapping keystrokes into editing functions, and something ELSE is constantly
reading the file buffer and updating the screen to make the changed buffer
always appear on the screen.  The screen updating has nothing to do with the
commands being executed.  The only influence they have on the screen is the
active window and cursor position, and the buffer contents.

If I build a key map to function that works just like vi, it will NOT
display just like vi.  I am working on just such a thing as an integral
part of a smart terminal program for my personal computer.  If such a
thing existed for YOUR personal computer, would it bother you that the
display would always show precisely what is in the file buffer as fast
as the screen can be updated (usually very fast)?  In an attempt to
modularize this program, this is the result I get.