GNU bug report logs - #26710
project-find-regexp blocks the UI

Previous Next

Full log

Message #40 received at 26710 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: hariharanrangasamy <at> gmail.com, 26710 <at> debbugs.gnu.org
Subject: Re: bug#26710: Fwd: 25.2; project-find-regexp makes emacs use 100% cpu
Date: Tue, 02 May 2017 20:26:19 +0300

> Cc: hariharanrangasamy <at> gmail.com, 26710 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Tue, 2 May 2017 13:00:06 +0300
> 
> On 02.05.2017 10:15, Eli Zaretskii wrote:
> 
> > Can you explain the significance of xref--regexp-syntax-dependent-p's
> > tests?  I don't know enough about xref to grasp that just by looking
> > at the changes.
> 
> When it returns nil (the regexp is not affected by syntax-table):
> 
> If the file containing the hit is not open, we now skip inserting the 
> first few lines of that file into the temporary buffer, and calling 
> set-auto-mode.
> 
> And, whether it's open or not, we skip the syntax-propertize call.

OK, I will look at that function with this in mind.

> Still, if the filter function and sentinel functions take a lot of time 
> (and/or get called a lot), like it will be in this example, the UI can't 
> as responsive as usual, can it?

The sentinel/filter won't be called at all if keyboard/mouse input is
available.  Once they are called, if each call takes a long processing
time, the UI could feel sluggish, yes.  But I don't quite see how
using threads will avoid the same problem, since the mechanism for
thread switch is basically the same as for multiplexing UI with
subprocess output.

> I'd like a more general advice first. E.g. do we want to go this road? 

IMO, we should first explore the async subprocess road.

> It seems a bit brittle, though: if the process filter is supposed to be 
> calling the callback for each item, the callback has to be in place 
> right away. And the process will be started before that happens.

You can countermand that by using make-process with the :stop
attribute, then use 'continue-process' when everything is set up.

> We'll probably be saved by filters having to wait until the current 
> command finishes executing, though.

Not sure I follow you: a filter function is called whenever some
output arrives from the subprocess.  So they don't need to wait for
the subprocess to finish.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.