Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!tut.cis.ohio-state.edu!snorkelwacker!bloom-beacon!eru!luth!sunic!tut!santra!hemuli.atk.vtt.fi!jel
From: jel@tel3.tel.vtt.fi (Jerry Lahti)
Newsgroups: gnu.bash.bug
Subject: Suboptimal bash 1.04 display management
Message-ID: <JEL.89Dec27110013@tel3.tel.vtt.fi>
Date: 27 Dec 89 16:00:12 GMT
Sender: news@hemuli.atk.vtt.fi
Reply-To: lahti@tel.vtt.fi
Distribution: gnu
Organization: Technical Research Centre of Finland
Lines: 29

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??

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.

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...)

As you guessed I would like to have HACK_TERMCAP_MOTION to be
turned OFF by default in the next release.

A Happy New Year,

Jerry Lahti
Technical Research Centre of Finland, Telecom lab
Domains: lahti@tel.vtt.fi