GNU bug report logs - #4887
globalized-minor-modes in new fundamental mode buffers

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 4887 in the body.
You can then email your comments to 4887 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Mark Lillibridge <mark.lillibridge <at> hp.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 23.1; list-load-path-shadows produces broken buffer
Date: Sat, 7 Nov 2009 21:34:54 -0800

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

Message #8 received at 4887 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: mark.lillibridge <at> hp.com
Cc: 4887 <at> debbugs.gnu.org
Subject: Re: bug#4887: 23.1; list-load-path-shadows produces broken buffer
Date: Mon, 09 Nov 2009 14:14:51 -0500

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.

Message #15 received at 4887 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Mark Lillibridge <mark.lillibridge <at> hp.com>
To: rgm <at> gnu.org
Cc: 4887 <at> debbugs.gnu.org
Subject: Re: bug#4887: 23.1; list-load-path-shadows produces broken buffer
Date: Wed, 11 Nov 2009 10:08:37 -0800

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

Message #20 received at 4887 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: mark.lillibridge <at> hp.com
Cc: 4887 <at> debbugs.gnu.org, rgm <at> gnu.org
Subject: Re: bug#4887: 23.1; list-load-path-shadows produces broken buffer
Date: Wed, 11 Nov 2009 15:40:48 -0500

>     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

Message #25 received at 4887 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Mark Lillibridge <mark.lillibridge <at> hp.com>
To: monnier <at> iro.umontreal.ca
Cc: 4887 <at> debbugs.gnu.org, rgm <at> gnu.org
Subject: Re: bug#4887: 23.1; list-load-path-shadows produces broken buffer
Date: Fri, 13 Nov 2009 13:57:10 -0800

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

Message #32 received at 4887 <at> debbugs.gnu.org (full text, mbox):

From: Mark Lillibridge <mark.lillibridge <at> hp.com>
To: mark.lillibridge <at> hp.com
Cc: rgm <at> gnu.org, monnier <at> iro.umontreal.ca, 4887 <at> debbugs.gnu.org
Subject: Re: bug#4887: 23.1; list-load-path-shadows produces broken buffer
Date: Wed, 6 Jan 2010 21:35:06 -0800

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

- Mark

Message #35 received at 4887 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: mark.lillibridge <at> hp.com
Cc: monnier <at> iro.umontreal.ca, 4887 <at> debbugs.gnu.org
Subject: Re: bug#4887: 23.1; list-load-path-shadows produces broken buffer
Date: Thu, 07 Jan 2010 00:48:08 -0500

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?

Message #38 received at 4887 <at> debbugs.gnu.org (full text, mbox):

From: Mark Lillibridge <mark.lillibridge <at> hp.com>
To: rgm <at> gnu.org
Cc: monnier <at> iro.umontreal.ca, 4887 <at> debbugs.gnu.org
Subject: Re: bug#4887: 23.1; list-load-path-shadows produces broken buffer
Date: Sat, 9 Jan 2010 16:47:10 -0800

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

Message #41 received at 4887 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: mark.lillibridge <at> hp.com
Cc: monnier <at> iro.umontreal.ca, 4887 <at> debbugs.gnu.org
Subject: Re: bug#4887: 23.1; list-load-path-shadows produces broken buffer
Date: Sun, 10 Jan 2010 20:52:30 -0500

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.