Helm: Slow Helm window and frame popup on Emacs 26+

[Ambrevar]

Expected behavior

Any Helm window should popup instatenously as with Emacs 25.3.

Actual behavior (from emacs-helm.sh if possible, see note at the bottom)

There is a noticeable lag (about 100-500 ms) when Helm windows pop up.

Steps to reproduce (recipe)

M-x helm-find-files, M-x helm-mini, anything.

Describe versions of Helm, Emacs, operating system, etc.

• Emacs 26.0.91
• Helm: MELPA master.
• OS: Void Linux.

Are you using emacs-helm.sh to reproduce this bug (yes/no): yes

[thierryvolpiatto]

Pierre Neidhardt [e-mail] writes:

Expected behavior

Any Helm window should popup instatenously as with Emacs 25.3.

Actual behavior (from emacs-helm.sh if possible, see note at the bottom)

There is a noticeable lag (about 100-500 ms) when Helm windows pop up.

I didn't try with windows but I noticed as well a delay with frames, see
helm-display-buffer-reuse-frame docstring.

You can try the following snippet with 25.3 and 26+:

(with-helm-in-frame
  (helm :sources (helm-build-sync-source "test"
                   :candidates '("foo" "bar" "baz"))
        :buffer "*helm test*"))

I think it is a emacs regression, don't know though if it is related to what
you see with helm windows on your side.

--
Thierry

[thierryvolpiatto]

I can't reproduce the lag with helm windows (or I don't see it), but with frames easily, the lag is about 1s before something is displaying in helm window whereas in emacs-25 it is instant.

[Ambrevar]

The delay varies, sometimes it's barely noticeable, sometimes it's outright annoying.
It seems to depend on the context, but I'm not quite sure what impacts it. I've never had this issue on Emacs 25.

I'll try to work it out.

[Ambrevar]

Note that I am on EXWM.

[Ambrevar]

OK, after more testing I think it's an EXWM issue. Let's leave this open until I get confirmation.

[thierryvolpiatto]

Pierre Neidhardt [e-mail] writes:

OK, after more testing I think it's an EXWM issue.

Looks like EXWM uses many hooks, window-configuration-change-hook,
post-command-hook, minibuffer-setup-hook etc...

Let's leave this open until I get confirmation.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.*

--
Thierry

[SwiftLawnGnome]

I seem to be having this problem too, on emacs 26.0.91. I actually noticed it because I opened emacs in a terminal and helm opened more or less instantly, which made me realize how much lag I've gotten used to in graphical emacs when invoking helm. It's worth noting that I do usually use EXWM, but I'm now in XFCE4 and graphical frames experience the same lag (possibly slightly less) as in EXWM. I also tried running a daemon, but the graphical frames spawned by emacsclient -c still had the delay.

[thierryvolpiatto]

Zach [e-mail] writes:

I seem to be having this problem too, on emacs 26.0.91. I actually
noticed it because I opened emacs in a terminal and helm opened more
or less instantly, which made me realize how much lag I've gotten used
to in graphical emacs when invoking helm. It's worth noting that I do
usually use EXWM, but I'm now in XFCE4 and graphical frames experience
the same lag (possibly slightly less) as in EXWM. I also tried running
a daemon, but the graphical frames spawned by emacsclient -c still had
the delay.

Thanks to confirm, this is a regression of emacs-26.

--
Thierry

[thierryvolpiatto]

Here again the code to try on emacs-25 and 26 to easily see the difference:

(with-helm-in-frame
  (helm :sources (helm-build-sync-source "test"
                   :candidates '("foo" "bar" "baz"))
        :buffer "*helm test*"))

Even with helm-display-buffer-reuse-frame emacs-26 is slower to raise frame than on emacs-25 with helm-display-buffer-reuse-frame nil.

[Ambrevar]

I've reported the issue upstream: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=30995.

[thierryvolpiatto]

Thanks.
Seems this issue have been fixed upstream by commit 2a192e2 done by @npostavs

[thierryvolpiatto]

Issue is fixed for me with frames, do you still have slowness with windows ?

[Ambrevar]

I'll let you know as soon as possible.

[SwiftLawnGnome]

Issue is fixed for me with frames, do you still have slowness with windows ?

I just built from master and opening a helm window is now next to instant. I don’t know how I put up with it on the alpha build quite honestly. Emacs in general seems a bit snappier, but that might be either placebo or just a result of helm itself being so much faster.

[npostavs]

I expect that doing (setq x-wait-for-event-timeout nil) should fix the issue on Emacs 26 as well.

[thierryvolpiatto]

Noam Postavsky [e-mail] writes:

I expect that doing (setq x-wait-for-event-timeout nil) should fix the issue on Emacs 26 as well.

Ok, thanks for your work on this.

--
Thierry

[Ambrevar]

Fixed indeed!

[Ambrevar]

Thank you @npostavs!

[zaeph]

Hello,

Following emacs’s 26.1 release, I’ve been experiencing the delays described in this issue.

There’s a significant hang running the following code (mentioned above):

(with-helm-in-frame
  (helm :sources (helm-build-sync-source "test"
                   :candidates '("foo" "bar" "baz"))
        :buffer "*helm test*"))

It happens both when calling helm in windows (e.g. helm-mini) or frames (e.g. code above).

Could someone look into it to see if they can reproduce it?

(I’m new to GitHub, so please excuse me if it’s not proper to comment on a closed issue.)

[thierryvolpiatto]

So on emacs-26 please follow @npostavs advice:
(setq x-wait-for-event-timeout nil)

Thanks.

[Ambrevar]

Now that Emacs 26.1 is out, should we make this more explicit?
I would at least include it in the installation section of the readme.
What about setting it by default, in helm-config.el or maybe in (helm-mode)?

[thierryvolpiatto]

Pierre Neidhardt [e-mail] writes:

Now that Emacs 26.1 is out, should we make this more explicit?
I would at least include it in the installation section of the readme.

Yes or/and adding an entry to FAQ in helm wiki.

>

What about setting it by default, in helm-config.el or maybe in
(helm-mode)?

No, it is too specific, it depends on various system and also on emacs
versions, lets users setting this themself, also it is not something that
prevent using helm, it just add a little delay when displaying a window
or a frame and this actually only on emacs-26.

The only option would be to let-bind the variable in helm-internal or
helm-display-buffer, but again we would have to declare it for emacs-25 (noop)
and it is not needed for 27.

NOTE: helm-mode is not the place for such settings.

--
Thierry

[thierryvolpiatto]

Just added an entry in wiki:
https://github.com/emacs-helm/helm/wiki/FAQ#slow-frame-and-window-popup-in-emacs-26

[Ambrevar]

Thanks!

[starenka]

I expect that doing (setq x-wait-for-event-timeout nil) should fix the issue on Emacs 26 as well.

man, this speeds up my helm million times! kudos!

[tomasorti]

Guys, do you know that setting

(setq x-wait-for-event-timeout nil)

makes Emacs on Microsoft Windows 10 unusable?

"GNU Emacs 26.1 (build 1, x86_64-w64-mingw32) of 2018-05-30"

[npostavs]

do you know that setting (setq x-wait-for-event-timeout nil) makes Emacs on Microsoft Windows 10 unusable?

I didn't know that, please report it to [email protected]; if you can check a 26.2 pretest that would be helpful too.

[tomasorti]

I didn't know that, please report it to [email protected]; if you can check a 26.2 pretest that would be helpful too.

How do I get a 26.2 pretest emacs for Windows?
I can't find it in any of those:

• http://ftpmirror.gnu.org/emacs
• http://ftp.gnu.org/gnu/emacs/windows/emacs-26

[npostavs]

Try https://alpha.gnu.org/gnu/emacs/pretest/windows/emacs-26/, (26.1.91 is the current pretest for 26.2)

[tomasorti]

http://emacs.1067599.n8.nabble.com/bug-34575-Setting-x-wait-for-event-timeout-to-nil-makes-Emacs-unusable-on-Windows-td476074.html