Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!apple!bbn!news
From: news@bbn.COM (News system owner ID)
Newsgroups: gnu.bash.bug
Subject: Re: Suboptimal bash 1.04 display management
Message-ID: <50243@bbn.COM>
Date: 1 Jan 90 23:37:53 GMT
References: <JEL.89Dec27110013@tel3.tel.vtt.fi>
Reply-To: pplacewa@antares.bbn.com (Paul W Placeway)
Distribution: gnu
Organization: Bolt Beranek and Newman Inc., Cambridge MA
Lines: 45

In article <JEL.89Dec27110013@tel3.tel.vtt.fi> lahti@tel.vtt.fi writes:
< The file
< readline.c provides a switch 'HACK_TERMCAP_MOTION' which controls
< if TERMCAP sequences are used to move the cursor to the right or not.
< In the distribution it is on by default although the comments in the
< code say that the alternative (i.e. moving right by simply rewriting
< the command line) would be faster.  Is there any compelling reason
< why simple rewriting cannot be used by default??

Actually, I just sent diffs to Brian that do all the Right Things to
make parameterized motion work (for instance, "<ESC>[20C").  Hopefully
they can be worked into place quite quickly.

The good news is that HACK_TERMCAP_MOTION goes away.  The bad news is
that the code that stays is the #ifdef case....

I suppose in general rewriting could (should) be used if there is no
parameterized movement or absolute horisontal position available.  On
the other hand, the smarter the code is for terminal features, the
more critical it is to *actually* be in the right position when doing
things with the cursor: as long as you play by the rules, life is
fine.  (BTW: I wrote the "rewriting is faster" comment)

< Our experience is that '#define HACK_TERMCAP_MOTION' produces very
< irritating results with a slow terminal line and a VT220 emulator;
< it is not very nice to receive tons of <ESC>[C's over a 1200 bps
< modem line when bash skips over the working directory part of a
< user's prompt.  Things would be better if bash were smart enough to
< send just <ESC>[20C but unfortunately there is no nd/ND TERMCAP
< capability pair similar to the dc/DC pair.

That's because you are looking for it under an antiquated name.  Try
"RI" (along with "LE", "UP", and "DO").  See RMS's termcap manual.

< Besides, if the prompt contains embedded terminal control sequences
< HACK_TERMCAP_MOTION will misplace the cursor.  (Some people
< like brightly coloured prompts or having the working directory
< on the status line of their terminal...)

If you do this, then you get what you desirve: a screwed up prompt.
If there is enough call for highlighted prompts, I'll proabably go off
and figure out how to do it reasonably (using symbolic sequences for
so/se, etc.).

		-- Paul Placeway <pplaceway@bbn.com>