jel@tel3.tel.vtt.fi (Jerry Lahti) (12/28/89)
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
news@bbn.COM (News system owner ID) (01/02/90)
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>trost@reed.bitnet (Bill Trost) (01/03/90)
In article <50243@bbn.COM> pplacewa@antares.bbn.com (Paul W Placeway) writes: >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.). Something in the back of my head is inclined to agree; however, I'd still like to push for having the prompt display use only the stuff after the last newline in the prompt for its cursor control. (Hmm, now something in the back of my head is saying "Well, write it already".... :-) ) --- trost%reed@tektronix.tek.com
news@bbn.COM (News system owner ID) (01/04/90)
(The topic is arbitrary display controls in the prompt.) In article <13816@reed.UUCP> trost@reed.bitnet (Bill Trost) writes: < In article <50243@bbn.COM> pplacewa@antares.bbn.com (Paul W Placeway) writes: < >If you do this, then you get what you desirve: a screwed up prompt. < < Something in the back of my head is inclined to agree; however, I'd < still like to push for having the prompt display use only the stuff < after the last newline in the prompt for its cursor control. This shouldn't be too hard, but it requires a new conceptual model of a prompt to really do right: a prompt would have two parts, some number of lines of anything at all (but a countable number of lines), and a final (possibly empty) partial line. For complete redisplays, the cursor should be moved to the beginning of the first part (in other words, up F lines, doing clear-to-eol's on each along the way), then the arbitrary text drawn, and finally the partial line and any text drawn. Line updates would only need to pay attention to the partial line, and only the partial line would need to be included in the current screen/next screen update buffers. Having said that, it shouldn't be too hard (famous last words). < (Hmm, now something in the back of my head is saying "Well, write it < already".... :-) ) Like I just said... :-) -- Paul <pplaceway@bbn.com>