bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#27115: Infinite loop created by fixing 26097


From: Eli Zaretskii
Subject: bug#27115: Infinite loop created by fixing 26097
Date: Wed, 31 May 2017 12:26:04 +0300

> From: Codrut Gusoi <codrut.gusoi@gmail.com>
> Date: Sun, 28 May 2017 14:39:42 +0300
> 
> 1) I am using Spacemacs
> (https://github.com/sdwolf/spacemacs/tree/develop) with evil and helm.
> 2) I have linum active.
> 3) I press "M-x" which is bound to (helm-M-x). This opens helm and
> triggers something called "Auto Evilification". Somewhere in this
> process the following message is displayed:
> 
> ```
> Auto-evilification could not remap these functions in map ‘edebug-mode-map’:
>    - ‘edebug-Go-nonstop-mode’ originally mapped on ‘G’
> ```
> 
> This is a single string with multiple "\n" inside it that can be
> generated by the following code (extracted from Spacemacs):
> 
> ```
> (setq my-map-symbol 'edebug-mode-map)
> (setq my-pending-funcs '((edebug-Go-nonstop-mode . 71)))
> (message (concat (format (concat "Auto-evilification could not remap
> these " "functions in map `%s': \n") my-map-symbol) (mapconcat (lambda
> (x) (format " - `%s' originally mapped on `%s'" (car x)
> (single-key-description (cdr x)))) my-pending-funcs "\n")))
> ```
> 
> 4) After the above message is displayed emacs freezes.

This seems to be due to a bug in Spacemacs's customization of
linum-mode.  The details are below, but first 2 possible workarounds:

Workaround #1: set resize-mini-windows to nil.
Workaround #2: Remove the after-advice from linum-update-window:

  M-: (advice-remove 'linum-update-window 
'spacemacs//linum-update-window-scale-fix) RET

Details:

The problem starts with linum's linum-after-scroll function, which is
installed in the window-scroll-functions hook, called by redisplay.
linum-after-scroll calls linum-update, which calls
linum-update-window, which decides, in the above scenario, to set the
window's left margin width to 3.  On a TTY, this requires adjustment
of the frame's glyph matrices, which causes the frame's garbaged flag
to become set.

This alone would not have caused redisplay to infloop, because the
next redisplay retry would find the window's margins already set to the
correct value, and would not require adjustment of frame's glyph
matrices.  However, Spacemacs installs an after-advice for
linum-update-window, which in this scenario resets the margin width
back to 1.  So, the next redisplay retry will again try to enlarge the
margin width to 3, which will cause the frame's garbaged flag to be
set, etc. etc., ad nauseam.

I think the bug is in Spacemacs's advice function, but I have no clear
understanding what it tries to do, and why in this case it decides to
reset the margin width to 1.

So I installed a band-aid, which will discontinue the retries after a
few attempts, just so Emacs remains usable.  Note that in the above
scenario this causes the frame's display to be slightly incorrect: the
mode line of one of the windows is not redrawn.  I'm deliberately not
going to try to fix this, because I think the underlying bug is in
Spacemacs, and should be fixed there.

Last, but not least: thank you for giving me a login on your system
and arranging for a very easy reproduction of the problem.  This made
debugging very easy.

I'll leave this bug open, in case followup discussions bring up
additional issues or better ideas for fixing this scenario.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]