unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Codrut Gusoi <codrut.gusoi@gmail.com>
Cc: 27115@debbugs.gnu.org
Subject: bug#27115: Infinite loop created by fixing 26097
Date: Wed, 31 May 2017 12:26:04 +0300	[thread overview]
Message-ID: <8337ble5sj.fsf@gnu.org> (raw)
In-Reply-To: <CAJi2ve4F7_ihWWw82n9xHRZ6bhmtQ3POkaSqWxv7bV4zjG9oQg@mail.gmail.com> (message from Codrut Gusoi on Sun, 28 May 2017 14:39:42 +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.





  parent reply	other threads:[~2017-05-31  9:26 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-28 11:39 bug#27115: Infinite loop created by fixing 26097 Codrut Gusoi
2017-05-28 15:28 ` Eli Zaretskii
     [not found]   ` <CAJi2ve63ZJC7qQr19fSLMdpEzfp8s3vcpf07RcHVOdz98Zmt=Q@mail.gmail.com>
2017-05-28 15:35     ` bug#27115: Fwd: " Codrut Gusoi
2017-05-31  9:26 ` Eli Zaretskii [this message]
2017-06-01 14:14   ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8337ble5sj.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=27115@debbugs.gnu.org \
    --cc=codrut.gusoi@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).