From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12178 invoked from network); 26 Aug 2000 20:46:56 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 26 Aug 2000 20:46:56 -0000 Received: (qmail 14745 invoked by alias); 26 Aug 2000 20:46:22 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 12705 Received: (qmail 14738 invoked from network); 26 Aug 2000 20:46:22 -0000 Subject: Re: A different approach to PROMPT_CR In-Reply-To: <1000826175034.ZM13455@candle.brasslantern.com> from Bart Schaefer at "Aug 26, 2000 05:50:34 pm" To: Bart Schaefer Date: Sat, 26 Aug 2000 21:46:51 +0100 (BST) CC: zsh-workers@sunsite.auc.dk X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: From: 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