bug#4878: 23.1; linum mode fails to work with Rmail correctly

bug#4878: 23.1; linum mode fails to work with Rmail correctly

[Mark Lillibridge]

Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the bug-gnu-emacs@gnu.org mailing list,
and to the gnu.emacs.bug news group.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

[Emacs version 23.1 for Microsoft Windows, but should fail also for
Linux, etc.]

* Turn on linum mode via global-linum-mode
* start Rmail.  
* use 'i' to open an existing Rmail file with multiple messages
* type 'h' to open and go to the Rmail summary buffer
* move between messages in the summary via the up and down arrows
* observe that the associated Rmail buffer window shows the current
  message as you move around in the summary buffer, but its line numbers
  are not updated (BUG)


I believe I understand the cause of this problem:

linum.el relies on a post-command-hook to determine when to update a
buffer:

linum.el:79:
        (if linum-eager
            (add-hook 'post-command-hook (if linum-delay
                                             'linum-schedule
                                           'linum-update-current) nil t)
          (add-hook 'after-change-functions 'linum-after-change nil t))

linum.el:113:
(defun linum-update-current ()
  "Update line numbers for the current buffer."
  (linum-update (current-buffer)))

(by default, linum-eager is t and linum-delay is nil).


The Rmail summary buffer also relies on a post-command-hook to update
the associated Rmail buffer:

rmailsum.el:901:
(defun rmail-summary-enable ()
  (use-local-map rmail-summary-mode-map)
  (add-hook 'post-command-hook 'rmail-summary-rmail-update nil t)
  (setq revert-buffer-function 'rmail-update-summary))


    When you type an arrow key in the Rmail summary buffer,
rmail-summary-rmail-update updates the associated Rmail buffer; if
linum-update-current runs afterwards (by default it seems to run before
hand, but I manually made run afterwords via remove/add-hook), it
updates the Rmail summary buffer but not the Rmail buffer itself.  Linum
seems to incorrectly assume that no command ever modifies any buffer
other than the current one, which is definitely false in this case.

    As an attempted fix, I added the linum after-change-functions hook
to the Rmail buffer.  This also failed to solve the problem, presumably
because changing the currently displayed message only involves altering
the restriction, not changing the buffer itself.


    Since I am guessing Rmail is not the only subsystem where one
command alters a different buffer or only changes a restriction in a
different buffer, linum should be fixed rather than Rmail.  The safest
solution is probably to have linum-update-current just update all buffers.
This strikes me as expensive if there are a lot of buffers, so maybe you
can find a better solution.

- Mark



If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
If you would like to further debug the crash, please read the file
c:/Program Files (x86)/Emacs/etc/DEBUG for instructions.


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: RMAIL Summary

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

Recent input:
v <delete> <return> <up> <up> C-h v <return> C-x o 
<next> <prior> C-x o C-x 1 <next> <next> <next> <prior> 
<prior> <prior> <prior> <prior> <prior> <next> <next> 
<switch-frame> <down-mouse-1> <mouse-movement> <mouse-1> 
<help-echo> <help-echo> <down-mouse-1> <mouse-movement> 
<mouse-movement> <drag-mouse-1> <down> <down> <down> 
<down> <up> . <down> <down> <down> <up> <up> <up> <up> 
<up> <up> <up> n n n n p p p p p n n <switch-frame> 
<down-mouse-1> <mouse-movement> <mouse-movement> <drag-mouse-1> 
<switch-frame> <down-mouse-1> <mouse-1> <escape> : 
C-y <return> C-x o <down> <down> <down> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <down> <down> <down> 
<down> <down> <down> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> C-x o C-x o t t <down> <down> <down> 
t t <down> <down> <down> t t <down> <down> <down> <up> 
<up> <up> t t <down> <down> <down> SPC SPC SPC SPC 
SPC <backspace> <backspace> <backspace> <backspace> 
<up> <up> <up> <up> SPC SPC \ <backspace> <backspace> 
<down> SPC <down> SPC <backspace> <switch-frame> <down-mouse-1> 
<mouse-movement> <mouse-1> C-h a h o o k <return> C-h 
? d h o o k <return> C-x 1 C-x b <return> C-h d h o 
o k s <return> <help-echo> <down-mouse-1> <mouse-1> 
C-x 1 <next> <next> <next> <next> <next> <next> <next> 
<next> <next> <next> <next> <next> <next> <next> <next> 
<next> <next> <next> <next> <next> <next> <next> <next> 
<next> <next> <next> <next> <next> <next> <next> <next> 
<next> <next> <next> <next> <next> <next> <next> <next> 
<next> <next> <next> <next> <next> <next> <next> <next> 
<next> <next> <next> <next> <next> C-h f n a r r o 
w <tab> <tab> r e <tab> <return> <help-echo> <help-echo> 
<help-echo> <down-mouse-1> <mouse-1> C-h v C-S-g <escape> 
x v c e r s <tab> <backspace> <backspace> <backspace> 
<backspace> e r s <tab> <return> <help-echo> <down-mouse-1> 
<mouse-1> <help-echo> <switch-frame> <down-mouse-1> 
<mouse-1> <escape> x r e p o <tab> r <tab> <return
>

Recent messages:
Showing message 7
Showing message 7...done
Type C-x 1 to remove help window.  
Making completion list...
Type C-x 1 to delete the help window.
Quit
GNU Emacs 23.1.1 (i386-mingw-nt6.0.6002) of 2009-07-29 on SOFT-MJASON
Showing message 7
Showing message 7...done
Making completion list...

bug#4878: marked as done (23.1; linum mode fails to work with Rmail correctly)

[Emacs bug Tracking System]

[-- Attachment #1: Type: text/plain, Size: 892 bytes --]

Your message dated Sat, 07 Nov 2009 13:11:17 -0500
with message-id <87k4y2p5mi.fsf@stupidchicken.com>
and subject line Re: 23.1; linum mode fails to work with Rmail correctly
has caused the Emacs bug report #4878,
regarding 23.1; linum mode fails to work with Rmail correctly
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@emacsbugs.donarmstrong.com
immediately.)


-- 
4878: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=4878
Emacs Bug Tracking System
Contact owner@emacsbugs.donarmstrong.com with problems

[-- Attachment #2: Type: message/rfc822, Size: 8792 bytes --]

From: Mark Lillibridge <mark.lillibridge@hp.com>
To: bug-gnu-emacs@gnu.org
Subject: 23.1; linum mode fails to work with Rmail correctly
Date: Thu, 5 Nov 2009 22:48:45 -0800
Message-ID: <200911060648.nA66mjiA019689@mailhub-pa1.hpl.hp.com>


Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the bug-gnu-emacs@gnu.org mailing list,
and to the gnu.emacs.bug news group.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

[Emacs version 23.1 for Microsoft Windows, but should fail also for
Linux, etc.]

* Turn on linum mode via global-linum-mode
* start Rmail.  
* use 'i' to open an existing Rmail file with multiple messages
* type 'h' to open and go to the Rmail summary buffer
* move between messages in the summary via the up and down arrows
* observe that the associated Rmail buffer window shows the current
  message as you move around in the summary buffer, but its line numbers
  are not updated (BUG)


I believe I understand the cause of this problem:

linum.el relies on a post-command-hook to determine when to update a
buffer:

linum.el:79:
        (if linum-eager
            (add-hook 'post-command-hook (if linum-delay
                                             'linum-schedule
                                           'linum-update-current) nil t)
          (add-hook 'after-change-functions 'linum-after-change nil t))

linum.el:113:
(defun linum-update-current ()
  "Update line numbers for the current buffer."
  (linum-update (current-buffer)))

(by default, linum-eager is t and linum-delay is nil).


The Rmail summary buffer also relies on a post-command-hook to update
the associated Rmail buffer:

rmailsum.el:901:
(defun rmail-summary-enable ()
  (use-local-map rmail-summary-mode-map)
  (add-hook 'post-command-hook 'rmail-summary-rmail-update nil t)
  (setq revert-buffer-function 'rmail-update-summary))


    When you type an arrow key in the Rmail summary buffer,
rmail-summary-rmail-update updates the associated Rmail buffer; if
linum-update-current runs afterwards (by default it seems to run before
hand, but I manually made run afterwords via remove/add-hook), it
updates the Rmail summary buffer but not the Rmail buffer itself.  Linum
seems to incorrectly assume that no command ever modifies any buffer
other than the current one, which is definitely false in this case.

    As an attempted fix, I added the linum after-change-functions hook
to the Rmail buffer.  This also failed to solve the problem, presumably
because changing the currently displayed message only involves altering
the restriction, not changing the buffer itself.


    Since I am guessing Rmail is not the only subsystem where one
command alters a different buffer or only changes a restriction in a
different buffer, linum should be fixed rather than Rmail.  The safest
solution is probably to have linum-update-current just update all buffers.
This strikes me as expensive if there are a lot of buffers, so maybe you
can find a better solution.

- Mark



If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
If you would like to further debug the crash, please read the file
c:/Program Files (x86)/Emacs/etc/DEBUG for instructions.


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: RMAIL Summary

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

Recent input:
v <delete> <return> <up> <up> C-h v <return> C-x o 
<next> <prior> C-x o C-x 1 <next> <next> <next> <prior> 
<prior> <prior> <prior> <prior> <prior> <next> <next> 
<switch-frame> <down-mouse-1> <mouse-movement> <mouse-1> 
<help-echo> <help-echo> <down-mouse-1> <mouse-movement> 
<mouse-movement> <drag-mouse-1> <down> <down> <down> 
<down> <up> . <down> <down> <down> <up> <up> <up> <up> 
<up> <up> <up> n n n n p p p p p n n <switch-frame> 
<down-mouse-1> <mouse-movement> <mouse-movement> <drag-mouse-1> 
<switch-frame> <down-mouse-1> <mouse-1> <escape> : 
C-y <return> C-x o <down> <down> <down> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <down> <down> <down> 
<down> <down> <down> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> C-x o C-x o t t <down> <down> <down> 
t t <down> <down> <down> t t <down> <down> <down> <up> 
<up> <up> t t <down> <down> <down> SPC SPC SPC SPC 
SPC <backspace> <backspace> <backspace> <backspace> 
<up> <up> <up> <up> SPC SPC \ <backspace> <backspace> 
<down> SPC <down> SPC <backspace> <switch-frame> <down-mouse-1> 
<mouse-movement> <mouse-1> C-h a h o o k <return> C-h 
? d h o o k <return> C-x 1 C-x b <return> C-h d h o 
o k s <return> <help-echo> <down-mouse-1> <mouse-1> 
C-x 1 <next> <next> <next> <next> <next> <next> <next> 
<next> <next> <next> <next> <next> <next> <next> <next> 
<next> <next> <next> <next> <next> <next> <next> <next> 
<next> <next> <next> <next> <next> <next> <next> <next> 
<next> <next> <next> <next> <next> <next> <next> <next> 
<next> <next> <next> <next> <next> <next> <next> <next> 
<next> <next> <next> <next> <next> C-h f n a r r o 
w <tab> <tab> r e <tab> <return> <help-echo> <help-echo> 
<help-echo> <down-mouse-1> <mouse-1> C-h v C-S-g <escape> 
x v c e r s <tab> <backspace> <backspace> <backspace> 
<backspace> e r s <tab> <return> <help-echo> <down-mouse-1> 
<mouse-1> <help-echo> <switch-frame> <down-mouse-1> 
<mouse-1> <escape> x r e p o <tab> r <tab> <return
>

Recent messages:
Showing message 7
Showing message 7...done
Type C-x 1 to remove help window.  
Making completion list...
Type C-x 1 to delete the help window.
Quit
GNU Emacs 23.1.1 (i386-mingw-nt6.0.6002) of 2009-07-29 on SOFT-MJASON
Showing message 7
Showing message 7...done
Making completion list...




[-- Attachment #3: Type: message/rfc822, Size: 2059 bytes --]

From: Chong Yidong <cyd@stupidchicken.com>
To: Mark Lillibridge <mark.lillibridge@hp.com>
Cc: 4878-done@emacsbugs.donarmstrong.com
Subject: Re: 23.1; linum mode fails to work with Rmail correctly
Date: Sat, 07 Nov 2009 13:11:17 -0500
Message-ID: <87k4y2p5mi.fsf@stupidchicken.com>

> Since I am guessing Rmail is not the only subsystem where one command
> alters a different buffer or only changes a restriction in a different
> buffer, linum should be fixed rather than Rmail.  The safest solution
> is probably to have linum-update-current just update all buffers.
> This strikes me as expensive if there are a lot of buffers, so maybe
> you can find a better solution.

I think this is enough of a corner case that we can patch up Rmail to
call linum-update specially (we can reconsider if more such cases pop
up).  I've checked such a fix into CVS.

Thanks for the bug report.