Re: callback api, isearch, signals issue

[Chet Ramey]

On 1/9/23 8:59 AM, Andrew Burgess wrote:

> A grep on the GDB source tree indicates we don't set
> rl_signal_event_hook anywhere.  I'll take a look now at the role that
> plays in this process and see if it will help at all, but I'd also
> welcome any insights you have.

The idea of the event hook is an application-specific event handler that
can be called after read is interrupted by a signal. The application is
the `agent' that has to decide what the effect of the signal should be.
To use bash as an example -- which does not use the callback interface --
it's the difference between what you do when SIGINT is trapped and when
it's set to the default disposition. Readline is agnostic in that regard.

So we're back to mismatched expectations. Readline is expecting the
application to abort the operation, and gdb expects readline to enforce
some behavior internally. We have a policy issue.

It's pretty clear that the desired behavior, at least for the purposes of
this report, here in the case of SIGINT during `stateful' operations like
search or digit-argument input is to abort, in the absence of any other
guidance from the application.

The question is who makes that decision, or at least enforces it. Should
readline impose some sort of default rl_abort behavior in the case that
application doesn't? That's easy enough to do in the signal cleanup path.
Or should it leave it completely up to the application to decide when to
call rl_abort or some other return to the top-levep REPL?

--
``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/