bug#4887: 23.1; list-load-path-shadows produces broken buffer

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

bug#4887: 23.1; list-load-path-shadows produces broken buffer

[Glenn Morris]

Mark Lillibridge wrote:

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

bug#4887: 23.1; list-load-path-shadows produces broken buffer

[Mark Lillibridge]

Glenn Morris wrote:
>  Mark Lillibridge wrote:
>  
>  > * 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.

    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

bug#4887: 23.1; list-load-path-shadows produces broken buffer

[Stefan Monnier]

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

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

bug#4887: 23.1; list-load-path-shadows produces broken buffer

[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

bug#4887: 23.1; list-load-path-shadows produces broken buffer

[Mark Lillibridge]

    Nothing appears to have been done about this bug since early
November.  What is the next step towards moving things forward?

- Mark

bug#4887: 23.1; list-load-path-shadows produces broken buffer

[Glenn Morris]

Mark Lillibridge wrote:

>     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?

bug#4887: 23.1; list-load-path-shadows produces broken buffer

[Mark Lillibridge]

Glenn wrote:
>  Mark Lillibridge wrote:
>  
>  >     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?

    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

bug#4887: 23.1; list-load-path-shadows produces broken buffer

[Glenn Morris]

Mark Lillibridge wrote:

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