Re: A different approach to PROMPT_CR

[Zefram <zefram@fysh.org>]

Bart Schaefer wrote:
>When promptnl runs, it asks the terminal to send back the current position
>of the cursor.  If the cursor is in column 1, it does nothing; otherwise it
>prints a newline.  Thus you get a newline exactly when one is needed.

This will eat any typeahead.  Actually, if an "R" is typed ahead it'll
get confused.  (Just pointing this out for discussion below.)

>for example use EOLMARK='%B!%b' to put a bold exclamation point at the end
>of the actual output.

This is neat, and solves one of my basic objections to shells outputting
a newline before the prompt (that it hides any missing-final-newline
bugs in programs that you run -- it's a bit of a feature of MS-DOS that
programs do that).

>This could be coded in C and added to ZLE ... `setopt PROMPT_NL', anyone?

Hmm.

There are two issues with doing it in the C code.  One is the matter
of putting terminal-specific features into the base shell.  This is
handleable: with PROMPT_NL set, we'd do this differently depending
on TERM.  With vt100-compatible terminals we'd do it the way your shell
function does, with other terminals we'd use different escape sequences,
and with unknown terminals we'd do nothing.

The other issue is the typeahead problem noted above.  Integrating this
into ZLE could mostly solve that.  Firstly, we can refuse to attempt
anything if we detect typeahead.  Then, for terminal types that return
the cursor position in a recognisable form, if what we get isn't in
the expected form we can abandon the attempt and use what we read as
normal input.  It'd still sometimes go wrong, particularly over slow
links, but of course it's easy to turn off.

-zefram