Re: Calling readline() a second or subsequent time and retaining state from previous calls

[Chet Ramey]

On 9/21/23 12:34 PM, Sam Habiel wrote:
> Hello there,
>
> Quick Intro: We have an interactive CLI for a language called M used in banking 
> and healthcare... I am working on adding readline integration as a nice to have 
> feature. We are an open source project located over here: 
> https://gitlab.com/YottaDB/DB/YDB.
>
> I sent an earlier message, and I thank Chet for the reply.
>
> I am dealing with the unpleasant for anybody to handle signals. One of our 
> signals suspends execution, completely unwinds the C stack (yes, we have lots 
> of assembly code for that), and then reissues the prompt. An example will help:
>
> YDB>write "f<cursor>o  <<< Receive SIGUSR1
>
> Once a SIGUSR1 is received, in the background, execution is suspended, a custom 
> function is executed, and the entire prompt code is actually processed, but the 
> user sees absolutely nothing of that. In the example above, the cursor will 
> stay between f and o. Our current code just sets up all the prompt data 
> structures from a saved structure when the signal is received.
>
> Is this possible with readline()? I naively tried rl_save_state() and 
> rl_restore_state(), but that doesn't seem to work.

SIGUSR1 isn't one of the signals readline handles by default, but it has
enough API functions available so that you can do it in your application.

All the necessary functions are in signals.c. The basic idea is that you
install your signal handler as usual, call the readline functions you
want to restore the terminal and anything else from the handler when it's
safe (look at _rl_signal_handler() for examples), then restore before your
handler returns (look at rl_cleanup_after_signal/rl_restore_after_signal).

If you want to split it up across calls to readline, you'll have to save
and restore a lot of state. I don't know if the information in
struct readline_state is enough for you -- it depends on your application
needs -- and it's not really intended to save and restore across calls
to readline(). It's mostly intended as a checkpoint during a single call,
so the interaction between the initialization readline does on each
invocation and the state restored isn't well exercised.

If you want to go further with that approach, you'll need at least a
startup hook to restore the state and do a redisplay before going on
in the second (post-signal) call to readline.

Chet

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