Re: [Bug-readline] Refresh readline notion of terminal size

[frederik]

Thanks Chet. I know Python and R have a similar model. I think the
question is not whether it is OK for Readline to take over the
application's signal handling, but whether it was OK for Readline to
catch signals and then forward them to the application - as it was
doing before 6.3. I could imagine problems like where an application
changes signal handlers after a call to Readline, but I don't think
anything like that was ever encountered or reported. Also there seems
to be a way to configure Readline to not do this, rl_catch_signals,
maybe for users like GDB that need finer control. These questions are
more along the lines of what I was referring to in my previous email.

> I will look for a way for applications to signal to readline that
> they are going to use the callback interface like this and cause
> readline's signal handlers to persist throughout a series of calls
> that collects a complete line. This will make the signal handling
> similar to a call to readline().

That would be great. Also, a standard way to clear the line on
interrupt would be useful as well, that could be the default SIGINT.

Frederick

On Sun, Jul 17, 2016 at 02:48:18PM -0400, Chet Ramey wrote:
> On 7/14/16 3:22 PM, address@hidden wrote:
> 
> > I actually still don't understand Chet's position regarding signal
> > handling, FWIW.
> 
> I know.  Let's see if I can illustrate it using a model that I touched
> on a little in my message to the python folks back in March.
> 
> Consider an application that uses multiple threads and multiple processes,
> and uses an event-driven model to switch between them.  In this model,
> the application tests various input and output sources and multiplexes
> between them, and uses signals to perform various control and user
> interface functions while that's happening.  Instead of sitting in a
> single select() loop waiting for input on readline's input file descriptor,
> it uses a select loop to wait for events from multiple sources.  Since
> there are more things happening than just sitting and blocking on input,
> and more events to be handled than just a character on the standard input
> that needs to be collected, readline should not keep its signal handlers
> installed.  The application needs to be able to handle signals while it's
> doing other things.
> 
> The readline callback interface needs to be flexible enough to accommodate
> applications that use select to multiplex between multiple threads and
> input sources and those that just use select to block waiting for input
> on the terminal file descriptor.  Readline can't presume to steal signals
> that the application might use for other purposes while it's not active
> in rl_callback_read_char().
> 
> Frankly, there's no real compelling reason for an application that just
> sits in a select loop and calls rl_callback_read_char() to do things that
> way.  There's no real difference between that and calling readline().  I
> will look for a way for applications to signal to readline that they are
> going to use the callback interface like this and cause readline's signal
> handlers to persist throughout a series of calls that collects a complete
> line.  This will make the signal handling similar to a call to readline().
> 
> Chet
> -- 
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>                ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, UTech, CWRU    address@hidden    http://cnswww.cns.cwru.edu/~chet/
>