On 11/28/17 6:20 AM, Rin Okuyama wrote:
>> Let's back up a bit. Why is Gnuplot attempting to use the readline signal
>> handling framework when there isn't any readline code executing? Is the
>> function fragment you showed assigned to rl_getc_function? If that's the
>> case, I can see a reason to allow rl_getc replacements to use the readline
>> signal handling infrastructure.
>
> Exactly. The function shown above is a simplified version of getc_wrapper(),
> which gnuplot substitutes into rl_getc_function. For more details, please
> refer to src/readline.c, as well as x11_waitforinput() in term/x11.trm,
> which is called from getc_wrapper() via term->waitforinput(). I think that
> the fragment captures the essence of it although... Anyway, gnuplot assigns
> that function to rl_getc_function, in order to catch inputs both from tty
> and mouse (``external_fd'' in the above code). Gnuplot does not install any
> signal handlers by its own.
OK. I'll add something like rl_check_signals() to wrap the RL_CHECK_SIGNALS
macro that rl_getc uses. That should provide the functionality that apps
that assign a value to rl_getc_function need to handle signals. Thanks for
the discussion.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU [email protected] http://cnswww.cns.cwru.edu/~chet/
_______________________________________________
Bug-readline mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-readline
