New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crash on C-g after C-x #130

Open
kimgronqvist opened this Issue Jul 8, 2016 · 24 comments

Comments

Projects
None yet
5 participants
@kimgronqvist

kimgronqvist commented Jul 8, 2016

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

This comment has been minimized.

Show comment
Hide comment
@justbur

justbur Jul 8, 2016

Owner

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?

Owner

justbur commented Jul 8, 2016

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?

@kimgronqvist

This comment has been minimized.

Show comment
Hide comment
@kimgronqvist

kimgronqvist Jul 9, 2016

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)

kimgronqvist commented Jul 9, 2016

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 added a commit that referenced this issue Jul 14, 2016

Add allow-imprecise-window-fit option
Possible fix for #130

When enabled this option avoids the use of fit-window-to-buffer to
resize the popup. My profiling suggested that emacs was spending a lot
of time in this function (and hanging sometimes) with different fonts. I
noticed this with Roboto Mono on MSWindows, which should explain #130.
@justbur

This comment has been minimized.

Show comment
Hide comment
@justbur

justbur Jul 14, 2016

Owner

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.

Owner

justbur commented Jul 14, 2016

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.

@kimgronqvist

This comment has been minimized.

Show comment
Hide comment
@kimgronqvist

kimgronqvist Aug 18, 2016

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.

kimgronqvist commented Aug 18, 2016

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.

@kimgronqvist

This comment has been minimized.

Show comment
Hide comment
@kimgronqvist

kimgronqvist Aug 18, 2016

Feels more like an upstream issue though.

kimgronqvist commented Aug 18, 2016

Feels more like an upstream issue though.

@justbur

This comment has been minimized.

Show comment
Hide comment
@justbur

justbur Aug 19, 2016

Owner

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.

Owner

justbur commented Aug 19, 2016

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.

@kimgronqvist

This comment has been minimized.

Show comment
Hide comment
@kimgronqvist

kimgronqvist Sep 17, 2016

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!

kimgronqvist commented Sep 17, 2016

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

This comment has been minimized.

Show comment
Hide comment
@justbur

justbur Sep 22, 2016

Owner

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?

Owner

justbur commented Sep 22, 2016

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

This comment has been minimized.

Show comment
Hide comment
@byronsanchez

byronsanchez Feb 7, 2017

@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.

byronsanchez commented Feb 7, 2017

@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.

@kimgronqvist

This comment has been minimized.

Show comment
Hide comment
@kimgronqvist

kimgronqvist Feb 9, 2017

@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.

kimgronqvist commented Feb 9, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@justbur

justbur Feb 9, 2017

Owner

Thanks for the pointer @kimgronqvist

Owner

justbur commented Feb 9, 2017

Thanks for the pointer @kimgronqvist

@ylluminarious

This comment has been minimized.

Show comment
Hide comment
@ylluminarious

ylluminarious Jun 14, 2018

@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.

ylluminarious commented Jun 14, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@justbur

justbur Jun 14, 2018

Owner

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

Owner

justbur commented Jun 14, 2018

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

@ylluminarious

This comment has been minimized.

Show comment
Hide comment
@ylluminarious

ylluminarious Jun 14, 2018

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

ylluminarious commented Jun 14, 2018

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

@ylluminarious

This comment has been minimized.

Show comment
Hide comment
@ylluminarious

ylluminarious Jul 8, 2018

@justbur Still happens on Emacs 26. Although, it is quite mitigated by using the new global-display-line-numbers-mode instead of global-linum-mode. I think that linum-mode was the bottleneck causing Emacs to hang in the first place.

I noticed previously that every time this issue happened, linum-mode would be turned on in buffers where it was supposed to be off. In Emacs 26, the same sort of thing happens; once Emacs hangs, there are line numbers in buffers where they were supposed to be off. But the hang doesn't last as long and it's not as severe, I guess because display-line-numbers-mode is implemented in C and is much faster than linum-mode.

ylluminarious commented Jul 8, 2018

@justbur Still happens on Emacs 26. Although, it is quite mitigated by using the new global-display-line-numbers-mode instead of global-linum-mode. I think that linum-mode was the bottleneck causing Emacs to hang in the first place.

I noticed previously that every time this issue happened, linum-mode would be turned on in buffers where it was supposed to be off. In Emacs 26, the same sort of thing happens; once Emacs hangs, there are line numbers in buffers where they were supposed to be off. But the hang doesn't last as long and it's not as severe, I guess because display-line-numbers-mode is implemented in C and is much faster than linum-mode.

@justbur

This comment has been minimized.

Show comment
Hide comment
@justbur

justbur Jul 13, 2018

Owner

@ylluminarious I just tried getting emacs to crash with global-linum-mode on, but I can't. I'm using emacs26 right now, too.

Owner

justbur commented Jul 13, 2018

@ylluminarious I just tried getting emacs to crash with global-linum-mode on, but I can't. I'm using emacs26 right now, too.

@ylluminarious

This comment has been minimized.

Show comment
Hide comment
@ylluminarious

ylluminarious Jul 13, 2018

@justbur It seems to happen sporadically, not consistently. Perhaps try it out at various intervals while doing different things with Emacs. I haven't pinned down the all of the exact circumstances which cause the hang.

ylluminarious commented Jul 13, 2018

@justbur It seems to happen sporadically, not consistently. Perhaps try it out at various intervals while doing different things with Emacs. I haven't pinned down the all of the exact circumstances which cause the hang.

@justbur

This comment has been minimized.

Show comment
Hide comment
@justbur

justbur Jul 13, 2018

Owner

@ylluminarious I'm not optimistic about finding this one on my own. Maybe you could seek help from emacs developers?

Owner

justbur commented Jul 13, 2018

@ylluminarious I'm not optimistic about finding this one on my own. Maybe you could seek help from emacs developers?

@Compro-Prasad

This comment has been minimized.

Show comment
Hide comment
@Compro-Prasad

Compro-Prasad Aug 15, 2018

Does setting inhibit-compacting-font-caches to nil help?

Compro-Prasad commented Aug 15, 2018

Does setting inhibit-compacting-font-caches to nil help?

@ylluminarious

This comment has been minimized.

Show comment
Hide comment
@ylluminarious

ylluminarious Aug 19, 2018

@Compro-Prasad I'm not sure... I've been running Emacs with it set as such for about a day or two and I haven't noticed the hang yet, but that doesn't mean it won't occur at some point in the future. However, given that I haven't seen it occur yet, it suggests in my mind that perhaps this variable and this issue are related. Emacs does seem to be consuming somewhat more memory than before after setting this variable... although this is to be expected as it says in the variable's docstring as well as the fact that I have lots of things going on in Emacs.

ylluminarious commented Aug 19, 2018

@Compro-Prasad I'm not sure... I've been running Emacs with it set as such for about a day or two and I haven't noticed the hang yet, but that doesn't mean it won't occur at some point in the future. However, given that I haven't seen it occur yet, it suggests in my mind that perhaps this variable and this issue are related. Emacs does seem to be consuming somewhat more memory than before after setting this variable... although this is to be expected as it says in the variable's docstring as well as the fact that I have lots of things going on in Emacs.

@ylluminarious

This comment has been minimized.

Show comment
Hide comment
@ylluminarious

ylluminarious Aug 27, 2018

@Compro-Prasad I've been running with that setting for the better part of a week now, so I'd say yes. Setting inhibit-compacting-font-caches to nil does seem to help. Ping @justbur

ylluminarious commented Aug 27, 2018

@Compro-Prasad I've been running with that setting for the better part of a week now, so I'd say yes. Setting inhibit-compacting-font-caches to nil does seem to help. Ping @justbur

@justbur

This comment has been minimized.

Show comment
Hide comment
@justbur

justbur Aug 28, 2018

Owner

@ylluminarious Sounds good, but I'm not sure I should change anything since it seems specific to a few users. I'd certainly keep this issue around, of course.

Owner

justbur commented Aug 28, 2018

@ylluminarious Sounds good, but I'm not sure I should change anything since it seems specific to a few users. I'd certainly keep this issue around, of course.

@Compro-Prasad

This comment has been minimized.

Show comment
Hide comment
@Compro-Prasad

Compro-Prasad Aug 28, 2018

@justbur Better mention in the README

Compro-Prasad commented Aug 28, 2018

@justbur Better mention in the README

@justbur

This comment has been minimized.

Show comment
Hide comment
@justbur
Owner

justbur commented Aug 28, 2018

justbur added a commit that referenced this issue Aug 28, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment