[Top][All Lists]

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

Re: [Bug-readline] Aborting reverse-i-search with the callback interface

From: Chet Ramey
Subject: Re: [Bug-readline] Aborting reverse-i-search with the callback interface
Date: Tue, 26 May 2015 19:51:28 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0

On 5/24/15 9:13 PM, Martin Panter wrote:
> This is regarding a bug reported for Python:
> <https://bugs.python.org/issue24266>, but I am wondering if it should
> actually be fixed inside Readline. When you press Ctrl+R, it switches
> to an incremental history search mode. In Bash, pressing Ctrl+C will
> cancel the entry completely, letting you start a new entry from
> scratch. However in Python, Ctrl+C clears the display, but does not
> actually cancel the search, and the entry is still there if you press
> enter. I noticed similar behaviour in GDB.

Thanks for the report.  This is an issue with the callback functionality
in readline, which is why bash doesn't exhibit the problem.

> Python uses the rl_callback_read_char() function to invoke Readline.
> It has a signal handler for SIGINT (Ctrl-C), which sets an exception
> flag, and then returns. If an exception is set, Python should abort
> the entry in Readline, and the next time we start calling Readline it
> should start a new entry. The code which handles this is at
> <https://hg.python.org/cpython/file/0d0989359bbb/Modules/readline.c#l1153>
> and looks a bit like this:
> s = PyErr_CheckSignals();
> if (s < 0) {
>     rl_free_line_state();
>     rl_cleanup_after_signal();
>     rl_callback_handler_remove();
>     *signal = 1;
>     completed_input_string = NULL;
> }
> The documentation of rl_free_line_state() at
> <https://cnswww.cns.cwru.edu/php/chet/readline/readline.html#IDX341>
> says it “will free any partial state”. I am far from an expert on
> Readline, but this sounds like it should clear the search mode and
> forget the searched entry. 

Not exactly.  `Line state' is more related to the actual line buffer:
the undo list, the state of any history entry being edited, whether
you're using a macro for input, a numeric argument, and so on.

Incremental search (and non-incremental search) are more global state,
since they give different characters different interpretations while in
that `mode', than state associated with the line buffer itself.

> A workaround has been proposed for Python
> to unset the RL_STATE_ISEARCH flag and set RL_STATE_DONE flag, but I
> wonder if you think this sort of thing should be done inside the
> rl_free_line_state() function instead?

That's part of the solution, and works for incremental search.  There
needs to be a more general solution for other `modes' that gets called
from the readline signal handler.


``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    address@hidden    http://cnswww.cns.cwru.edu/~chet/

reply via email to

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