Re: bracketed-paste-mode and gdb

[Andrew Burgess]

Chet Ramey <chet.ramey@case.edu> writes:

> On 2/17/22 2:46 PM, Andrew Burgess wrote:
>
>>> Right. I agree that this information is something that callback interface
>>> users would like to know, so let's figure out the best way to do it. Either
>>> way, it's an addition to the current readline API.
>> 
>> Thanks for the feedback.  I guess the next step to move this forward is
>> for me to draft an actual patch, with doc changes and all.  I'm happy to
>> work with either approach, the origina RL_STATE_EOF, or the rl_eof_found
>> strategy.  I guess I'd defer to your judgement for which you'd prefer.
>
> It should be just a matter of changing _rl_eof_found to rl_eof_found in
> the source, so that's not a problem. I may end up doing both, in the same
> way that rl_done and RL_STATE_DONE both exist.
>
> I'd appreciate your thoughts on a description.

Not sure if you mean description of the flag/state - or the patch as a
whole.

For the flag/state I guess:

    Readline has received, and is currently handling, and EOF character.

For the change as a whole:

    Advertise to users (of the API) when readline is processing an EOF
    character.  In normal use, after an end-user has entered a complete
    line, readline will have advanced the cursor to the next line.
    
    In contrast, when readline processes and EOF character, the cursor will
    not have been advanced to the next line.
    
    In order to work around this difference readline prints a "\n" character
    in rl_deprep_terminal when _rl_eof_found is true.
    
    Currently, when using the callbacks API, _rl_eof_found is never set, so
    the extra newline is never printed, this leaves the cursor on the same
    line as the prompt.  This patch fixes this bug.
    
    Additionally, if a user (of the API) wishes to print something to the
    prompt line when an EOF is received, before the newline is printed
    (e.g. some feedback to the user that EOF was received), then the obvious
    way to do this is to override rl_deprep_term_function, and print the
    feedback before calling rl_deprep_terminal.  However, there is currently
    no way for a user (of the API) to tell in a rl_deprep_term_function
    callback that readline is processing an EOF.
    
    This patch makes _rl_eof_found part of the readline API, and renames it
    to rl_eof_found and/or adds the RL_STATE_EOF state.  An API user can
    then check one of these within an rl_deprep_term_function callback to
    decide if any extra output should be printed.

I hope these help a little.  If there's anything at all I can do to help
with this, then please just let me know.

Many thanks,
Andrew