Crash on C-g after C-x

[k-ode]

Hi! Thanks for a great project, it's super useful.

However, I'm having some issues with frequent crashes on Windows with Emacs 25. If I press C-x followed by C-g (to abort the sequence), which-key almost always makes Emacs hang and become unresponsive.

This is on Windows 8 with Emacs 25.0.94.2.

Please let me know if you need to me to provide more information, or anything else I can do to help.

[justbur]

Hi, I haven't experienced this and I have a similar setup. What settings do you have for which-key and have you tried reproducing with emacs -Q?

[k-ode]

I don't experience the same crashes with emacs -Q. I've narrowed the problem down in my config, and it seems it's because I use a custom font.

(custom-set-faces
 ;; custom-set-faces was added by Custom.
 ;; If you edit it by hand, you could mess it up, so be careful.
 ;; Your init file should contain only one such instance.
 ;; If there is more than one, they won't work right.
 '(default ((t (:family "Roboto Mono" :foundry "outline" :slant normal :weight normal :height 98 :width normal :spacing c)))))

If i run my config with this code commented out, I have no issues. But if I evaluate this, which-key crashes after a couple of C-x C-g.

I get this issue regardless of which-key settings, but it does seem to trigger more often if the idle delay option is lower.

(setq which-key-idle-delay 0.4)

[justbur]

Try the new option in commit eb4a6f6

(setq which-key-allow-imprecise-window-fit t)

In my tests it appears to me that for some reason that font slows down the calculation of window sizes. My emacs seemed noticeably laggy when I used that font. which-key was lagging in one particular area and this variable allows you to bypass that calculation. It shouldn't make a huge difference, but let me know if you notice problems.

[k-ode]

Sadly, it doesn't seem to help much.

It's a really weird problem. It works fine with most fonts, but I've also seen this with Anonymous Pro.

[k-ode]

Feels more like an upstream issue though.

[justbur]

Hm, I don't know what to say. If you can profile which-key on your computer we might be able to narrow it down, but I'm not using windows at the moment, so I'm not sure what I can do on my side.

[k-ode]

Sorry for the delay. I've tried profiling this, but I can't really see a difference between using a "normal" font and a font that causes issues. Do you still want to see the result?

As you said, this feels more like a general issue with Emacs using those fonts. I'll prepare a bug report to Emacs.

Thanks for looking into this!

[justbur]

Sure, I'll take a look, but it does sound like an upstream issue. What version of emacs are you on now? Have you tried 25.1?

[byronsanchez]

@kimgronqvist - Quick question- was there ever a response from upstream and a place where this is currently being discussed? I have the exact same issue, except I'm using the font Ubuntu Mono (powerline version) on Windows with native Emacs v25.0.90.3.

[k-ode]

@byronsanchez I believe this is the same bug: https://lists.gnu.org/archive/html/bug-gnu-emacs/2016-10/msg00334.html

The workaround is supposed to be setting inhibit-compacting-font-caches to nil. I'm unsure if there is a release with this fix yet though, and I havn't personally tested it yet.

[justbur]

Thanks for the pointer @kimgronqvist

[ylluminarious]

@justbur I'm having the same issue as well. I was actually relieved to find this thread; this bug was driving me crazy and I was afraid that I was the only one. My current version info is as follows:

GNU Emacs 25.3.12 (x86_64-apple-darwin17.5.0, Carbon Version 158 AppKit 1561.4) of 2018-05-14

I.e., I'm on GNU Emacs 25.3 using the Emacs Mac Port by Yamamoto Mitsuharu. I'm also on macOS 10.13.5. It is possible that this issue is gone in Emacs 26, but I haven't used Emacs 26 yet and I can't remember reading anything about this bug in the NEWS file.

[justbur]

@ylluminarious Can you reproduce it with another build of emacs like this one?

[ylluminarious]

@justbur I'll try. I'll let you know what I find.