helm-locate only reluctantly quittable

[michael-heerdegen]

Hi,

helm.sh, M-x helm-locate RET, enter some string

C-g doesn't quit helm. I need to hit C-g multiple times to quit helm, preferably in fast succession.

The problem also occurs when you add helm-source-locate to helm-for-files-preferred-list.

[thierryvolpiatto]

Hi Michael,

michael-heerdegen notifications@github.com writes:

Hi,

helm.sh, M-x helm-locate RET, enter some string

C-g doesn't quit helm. I need to hit C-g multiple times to quit helm, preferably in fast succession.

It is a very strange bug only present in >emacs-24.3.

In helm-locate we are unable to C-g, or with difficulty as you said, and
in e.g helm-grep the quit occur but "Emacs-Lisp:" is sent in minibuffer.

I don't know yet what is happening here, I suspect an emacs bug as quit
is working fine in emacs-24.3.

Waiting for a fix, you can quit hitting C-! and C-g.

Thanks.

Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997

[michael-heerdegen]

Note that for every unsuccessful C-g, you get this message:

Error during redisplay: (#[128 "\300\301�\"\210\300\302�\"\207" [apply redisplay--update-region-highlights ignore nil] 4 nil nil] (#<window 174 on *helm locate*>)) signaled (quit)

So the quit signal seems to be processed while running redisplay--update-region-highlights. That ignores errors, but doesn't handle quit in any way. The quit makes redisplay raise an error. A strange behavior - why does any redisplay code process a quit singnal at all?

[michael-heerdegen]

But binding inhibit-quit around redisplay--update-region-highlights:

(defun redisplay--update-region-highlights (windows)
  (let ((inhibit-quit t))
    (with-demoted-errors "redisplay--update-region-highlights: %S"
      (if (null windows)
          (redisplay--update-region-highlight (selected-window))
        (unless (listp windows) (setq windows (window-list-1 nil nil t)))
        (if highlight-nonselected-windows
            (mapc #'redisplay--update-region-highlight windows)
          (let ((msw (and (window-minibuffer-p) (minibuffer-selected-window))))
            (dolist (w windows)
              (if (or (eq w (selected-window)) (eq w msw))
                  (redisplay--update-region-highlight w)
                (funcall redisplay-unhighlight-region-function
                         (window-parameter w 'internal-region-overlay))))))))))

doesn't solve the issue. The error messages disappear, but it seems the quit is silently caught somewhere instead of just delaying it.

[michael-heerdegen]

Whatever I tried, the quit is always caught by something run by redisplay. You can bind inhibit-quit non-nil anywhere, but then the quit signal causes an error somewhere else.

[thierryvolpiatto]

michael-heerdegen notifications@github.com writes:

Whatever I tried, the quit is always caught by something run by
redisplay. You can bind inhibit-quit non-nil anywhere, but then the
quit signal causes an error somewhere else.

Binding `pre-redisplay-function' fix the problem in emacs-24.4 branch,
however in emacs-trunk branch, the problem is still here, though
quitting is usable, but the error messages are there.

So it is really some recent changes in emacs-trunk that triggered this
(annoying) bug.

Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997

[michael-heerdegen]

I think you should make a bug report. Maybe it's easy to fix in Emacs, so we should not waste time trying to workaround this in helm.

[thierryvolpiatto]

michael-heerdegen notifications@github.com writes:

I think you should make a bug report. Maybe it's easy to fix in Emacs,
so we should not waste time trying to workaround this in helm.

Done

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17577

Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997

[thierryvolpiatto]

I have reenabled the fix.
We will have to live with this user error...
quitting is working now though.

[michael-heerdegen]

Thierry Volpiatto notifications@github.com writes:

I have reenabled the fix.

Now that it's fixed in Emacs, do we still need to bind
pre-redisplay-function?

[thierryvolpiatto]

michael-heerdegen notifications@github.com writes:

Thierry Volpiatto notifications@github.com writes:

I have reenabled the fix.

Now that it's fixed in Emacs, do we still need to bind
pre-redisplay-function?

Of course no, it have been fixed.

Thanks.

Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997

[michael-heerdegen]

Too bad - the situation has not improved for helm-for-files:

When you push helm-source-locate to helm-for-files-preferred-list, and
call helm-for-files, enter some string, and hit , you can't quit
helm until it has finished with whatever it did (displaying candidates?).
The problem does only occur when I hit at least one time.

I get a feedback when hitting C-g, so the event is not just swallowed,
but it doesn't quit helm.

[thierryvolpiatto]

michael-heerdegen notifications@github.com writes:

Too bad - the situation has not improved for helm-for-files:

It is not related, C-g is working as expected now.
This is an other issue that can be fixed easily, instead of hitting
directly , hit C-! and then .

Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997

[michael-heerdegen]

Thierry Volpiatto notifications@github.com writes:

This is an other issue that can be fixed easily, instead of hitting
directly , hit C-! and then .

Ok, C-! works. But why is it necessary? And is it necessarily
necessary?

[thierryvolpiatto]

michael-heerdegen notifications@github.com writes:

Thierry Volpiatto notifications@github.com writes:

This is an other issue that can be fixed easily, instead of hitting
directly , hit C-! and then .

Ok, C-! works. But why is it necessary? And is it necessarily
necessary?

Because the process buffer used by locate is the helm-buffer, which is
shared by all other sources.

Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997

[michael-heerdegen]

Thierry Volpiatto notifications@github.com writes:

Because the process buffer used by locate is the helm-buffer, which is
shared by all other sources.

Ok. But don't you agree that what we have is a bit awkward? I added
helm-source-locate to helm-for-files-preferred-list to save time. But
when I forget to C-!, I'm punished with 15 secs of extra waiting.

What I want is a quick way to switch to locate when I did not find
what I searched in file-cache/ recent files, etc, without loosing the
current input, and without punishments. I think that's a reasonable -
and not only my personal - wish.

[thierryvolpiatto]

michael-heerdegen notifications@github.com writes:

Ok. But don't you agree that what we have is a bit awkward?

I agree.

I was just showing what to do manually, i.e C-! +
to explain you how to fix the issue in helm-next-source, *next-line,
etc...

I will fix this ASAP.

I added helm-source-locate to helm-for-files-preferred-list to save
time.

Isn't it there by default ?

Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997

[thierryvolpiatto]

I close continue on #527