[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-readline] [PATCH] Gnuplot on macOS does not suspend by Control-

From: Chet Ramey
Subject: Re: [Bug-readline] [PATCH] Gnuplot on macOS does not suspend by Control-z
Date: Tue, 28 Nov 2017 10:16:19 -0800
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0

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.


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]