On 01/31/2017 07:48 AM, Eli Zaretskii wrote:
> Then maybe we should add maybe_quit calls in regex.c instead?

We already have them there, everywhere that the regex code could do a 
lot of computation. In places where it's fast and bounded, we don't have 
them as they would slow things down.

> Currently, immediate_quit is non-zero all the time re_search_2 runs,
> so on a TTY a C-g will can stop regex.c in its tracks anywhere.  I
> thought we wanted to make GUI sessions as responsive as TTY sessions.

That has not been my goal. C-g in GUI sessions is already plenty fast 
enough for human interaction. (If they are not, we should fix that; but 
I don't know of any bugs in the regexp-searching area.) Whatever way we 
do it, treating GUI and TTY sessions the same as far as quitting goes 
simplifies maintenance significantly.

>
>> It should be OK. The current master sets immediate_quit=true in back_comment's callers (both scan_lists and Fforward_comment), so current master already lets back_comment quit.
> Yes, but that is why we have gl_state-related dance in
> handle_interrupt, and your changes delete that part.

That gl_state-related dance is present only because 'quit ()' can return 
instead of quitting, which means that the code could asynchronously 
reenter the regexp code. Since that call to 'quit' is no longer present, 
that sort of reentry is no longer possible, and we don't need the dance.

>
>> If Emacs quits in back_comment, it should longjmp to code that reinitializes gl_state before using it.
> But unwinding the Lisp stack could run some Lisp that uses syntax.c
> functions, before we longjmp, right?

No, because the interruptible regexp code does not call Lisp code: it 
does not try to reenter itself.

> That assumes all the immediate_quit=true settings were safe.

That sort of thing has been in Emacs for ages, and I daresay it's been 
tested at least as well as, if not even more than, the GUI approach to 
quitting searching. When I was using Emacs in the 1980s computers were 
not nearly as fast and people's keystrokes were just as fast as they are 
now. So it's reasonable to place some confidence in those settings. 
Quite possibly we could make improvements in this area later, but it's 
conservative to stick with those settings for now.

> Speed is not a problem, as C-g (with the proposed changes) should quit just as fast on a TTY as it already does under X, and it's been working that way under X for some time.
> No, it will be slower.

Apparently I was not clear enough. I was not saying that the change 
won't delay C-g handling in ttys; obviously it will. All I was saying is 
that C-g will be handled as fast on ttys as it is on GUIs, which is good 
enough.

> The new patches still include both rarely_quit and incr_rarely_quit
> (in the second patchset), which I thought you decided to remove.  Did
> you send the correct patches?
Yes, the third patch removed incr_rarely_quit. I'm not a big fan of 
rewriting history. For your convenience I've attached a combined patch, 
that's just all the patches squashed together so that there isn't any 
incr_rarely_quit.