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 [email protected] http://tiswww.cwru.edu/~chet/
OpenPGP_signature.asc
Description: OpenPGP digital signature
