[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Superfluous newlines after ^D when using external event loop
From: |
Chet Ramey |
Subject: |
Re: Superfluous newlines after ^D when using external event loop |
Date: |
Mon, 12 Feb 2024 09:48:37 -0500 |
User-agent: |
Mozilla Thunderbird |
On 2/10/24 11:02 PM, Juerd Waalboer wrote:
Grepping the source for 2004l came up with BRACK_PASTE_FINI, and
specifically, the addition of a "\n" if bracketed paste is enabled and
rl_eof_found is true, in rl_deprep_terminal().
It does seem the \n is useful, but only once. However, because rl_eof_found
remains true, the \n is then printed after each input. With
readline_internal(), rl_eof_found is reset to false, but if you write your
own event loop, you'd have to do that yourself.
That seems reasonable. If your application wants to ignore EOF and go
back into rl_callback_read_char, shouldn't it be responsible for resetting
rl_eof_found? Its purpose, after all, is to communicate state to the
calling application.
The variable changed from private (_rl_eof_found) to public (rl_eof_found)
in bash-5.2/readline-8.2 just so applications could check it -- in
particular in the deprep-term hook or the line handler.
https://lists.gnu.org/archive/html/bug-readline/2022-01/msg00002.html
explains why the \n is there.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU chet@case.edu http://tiswww.cwru.edu/~chet/
OpenPGP_signature.asc
Description: OpenPGP digital signature