Re: A different approach to PROMPT_CR

Re: A different approach to PROMPT_CR

[Zefram]

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

Re: A different approach to PROMPT_CR

[Bart Schaefer]

On Aug 26,  9:46pm, Zefram wrote:
} Subject: Re: A different approach to PROMPT_CR
}
} This will eat any typeahead.  Actually, if an "R" is typed ahead it'll
} get confused.

Hmm, what will "stty -echo" do to typeahead?

Would it suffice to insert

if read -t -k 1
then
    print -z $REPLY
    return 0
fi

before the stty call?

It might be nice if "read -t -k 0" simply returned 0 if there's pending
input and 1 otherwise, without reading anything.  Right now, -k 0 is
treated the same as -k 1 (read always reads at least one byte).

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: A different approach to PROMPT_CR

[Peter Stephenson]

"Bart Schaefer" wrote:
> It might be nice if "read -t -k 0" simply returned 0 if there's pending
> input and 1 otherwise, without reading anything.  Right now, -k 0 is
> treated the same as -k 1 (read always reads at least one byte).

Yes, but I had to make it read a character as a last resort since on cygwin
checking for pending input didn't work.  Somebody will have to find a way
of making this work everywhere.  While there about it, they could also find
a way of making the read time out on all systems, which was the other thing
I tried to do.

-- 
Peter Stephenson <pws@pwstephenson.fsnet.co.uk>
Work: pws@csr.com
Web: http://www.pwstephenson.fsnet.co.uk