bug#4887: 23.1; list-load-path-shadows produces broken buffer
Mark Lillibridge
Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:
* turn on global-linum-mode
* run list-load-path-shadows
* observe that the resulting buffer, *Shadows*, has no line numbering,
even if you change into that buffer, move around, and change text. [BUG]
Some debugging shows that:
*Shadows* has a post-command-hook value (^h v) of nil, when it should
contain (linum-update-current t) locally and
(... global-linum-mode-check-buffers) globally.
Looking at the source code shows that the following code creates the
buffer *Shadows*:
shadows.el:239:
;; Create the *Shadows* buffer and display shadowings there.
(let ((output-buffer (get-buffer-create "*Shadows*")))
(display-buffer output-buffer)
(set-buffer output-buffer)
(erase-buffer)
(while shadows
(insert (format "%s hides %s\n" (car shadows)
(car (cdr shadows))))
(setq shadows (cdr (cdr shadows))))
(insert msg "\n")))
Some experimentation shows that the offending code is:
(get-buffer-create "*Shadows*")
If you just run this via eval-expression, a new buffer called *Shadows*
is created with a broken value of post-command-hook. I do not appear to
have source code for this function, so I leave the rest of the debugging
job to you...
- Mark
In GNU Emacs 23.1.1 (i386-mingw-nt6.0.6002)
of 2009-07-29 on SOFT-MJASON
Windowing system distributor `Microsoft Corp.', version 6.0.6002
configured using `configure --with-gcc (4.4)'
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: nil
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: ENU
value of $XMODIFIERS: nil
locale-coding-system: cp1252
default-enable-multibyte-characters: t
Major mode: Text
Minor modes in effect:
global-linum-mode: t
linum-mode: t
delete-selection-mode: t
pc-selection-mode: t
tooltip-mode: t
tool-bar-mode: t
mouse-wheel-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
global-auto-composition-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Glenn Morris
> * turn on global-linum-mode
> * run list-load-path-shadows
> * observe that the resulting buffer, *Shadows*, has no line numbering,
global-linum-mode is defined using the macro `define-globalized-minor-mode'.
From the Elisp manual entry on that macro:
Globally enabling the mode also affects buffers subsequently
created by visiting files, and buffers that use a major mode
other than Fundamental mode; but it does not detect the creation
of a new buffer in Fundamental mode.
And the *Shadows* buffer uses Fundamental mode.
Mark Lillibridge
Ok, how do we go about deciding where the bug(s) lies? Clearly,
linum is meant to work in all buffers:
linum.el:26:
;; Display line numbers for the current buffer.
;;
;; Toggle display of line numbers with M-x linum-mode. To enable
;; line numbering in all buffers, use M-x global-linum-mode.
This is the behavior I need -- I use voice commands to navigate among
lines and designate ranges of lines for operations -- so simply changing
linum's spec so that it does not work in fundamental buffers is
unacceptable.
Should linum use a different implementation method than
define-globalized-minor-mode? (does one exist?)
Should we instead fix define-globalized-minor-mode to work with all
buffers? Its documentation via ^h f claims it works in every buffer:
define-globalized-minor-mode is an autoloaded Lisp macro in
`easy-mmode.el'.
(define-globalized-minor-mode global-mode mode turn-on &rest keys)
Make a global mode global-mode corresponding to buffer-local minor mode.
turn-on is a function that will be called with no args in every buffer
and that should try to turn mode on if applicable for that buffer.
Clearly at a minimum this is inconsistent with
define-globalized-minor-mode's actual behavior and Elisp manual entry.
What do people think?
- Mark
Stefan Monnier
> define-globalized-minor-mode? (does one exist?)
You mean global-linum-mode? Yes, it could use a different method,
e.g. setting global hooks instead, but that might prove tricky.
> Should we instead fix define-globalized-minor-mode to work with all
> buffers? Its documentation via ^h f claims it works in every buffer:
That would be the best solution, yes.
Given the hooks we currently have, it's not very easy because buffers
like *Shadows* get created without running any hook, so basically the
first hook that would get triggered might be something like
window-configuration-change-hook, but that hooks has no easy way to
decide whether that buffer was just created recently or on the contrary
has been around for a long while (in which case enabling linum-mode
might be very wrong since the user may have turned it off there
earlier).
An easier solution is to not change anything to
define-globalized-minor-mode and to require Elisp code to explicitly set
a major mode for any buffer that will be displayed. E.g. for *Shadows*
the Elisp code should explicitly call fundamental-mode in it.
Stefan
Mark Lillibridge
> > Should linum use a different implementation method than
> > define-globalized-minor-mode? (does one exist?)
>
> You mean global-linum-mode? Yes, it could use a different method,
> e.g. setting global hooks instead, but that might prove tricky.
>
> > Should we instead fix define-globalized-minor-mode to work with all
> > buffers? Its documentation via ^h f claims it works in every buffer:
>
> That would be the best solution, yes.
I agree. Any fix that worked for global-linum-mode should
presumably be implemented as part of define-globalized-minor-mode so
that other global minor modes can benefit as well.
> Given the hooks we currently have, it's not very easy because buffers
> like *Shadows* get created without running any hook, so basically the
> first hook that would get triggered might be something like
> window-configuration-change-hook, but that hooks has no easy way to
> decide whether that buffer was just created recently or on the contrary
> has been around for a long while (in which case enabling linum-mode
> might be very wrong since the user may have turned it off there
> earlier).
I thought about using advice on get-buffer-create, but the manual
recommends creating a hook instead. Could we create a new-buffer hook?
That would certainly solve the problem and simplify
define-globalized-minor-mode. I wonder though, if this would call the
minor mode turn on function too early in some cases.
Alternatively, it doesn't look very hard to use
window-configuration-change-hook; we would have to add some storage to
remember which buffers we had already enabled any given minor mode in.
> An easier solution is to not change anything to
> define-globalized-minor-mode and to require Elisp code to explicitly set
> a major mode for any buffer that will be displayed. E.g. for *Shadows*
> the Elisp code should explicitly call fundamental-mode in it.
This would work as well; who makes the call on these sorts of things?
(This is a change of conventions more than a code patch.)
- Mark
Glenn Morris
> Nothing appears to have been done about this bug since early November.
2009-11-24 Stefan Monnier <monnier at iro.umontreal.ca>
* emacs-lisp/shadow.el (list-load-path-shadows): Setup a major
mode for the displayed buffer (bug#4887).
Or were you refering to the more general issue?
Mark Lillibridge
Nothing appears to have been done about this bug since early
- Mark
Mark Lillibridge
Glenn wrote:
> Mark Lillibridge wrote:
>
> > Nothing appears to have been done about this bug since early November.
>
>
> * emacs-lisp/shadow.el (list-load-path-shadows): Setup a major
> mode for the displayed buffer (bug#4887).
>
> Or were you refering to the more general issue?
Ah. I was not aware of that as I haven't received any email to that
effect. How should I've gotten this information? It doesn't show up
with Google.
Yes, that fixes the immediate bug. I will submit another bug if I
run across another buffer created without setting a mode.
- Thanks,
Mark
Glenn Morris
> Ah. I was not aware of that as I haven't received any email to that
> effect.
I don't think any email was sent about this change (until now), so
there was no way for you to know without monitoring the ChangeLog.
Sorry.