Problems fontifying an autoreverting Buffer Menu

Problems fontifying an autoreverting Buffer Menu

[Luc Teirlinck]

If you do:

emacs -q -nbc &
M-x global-font-lock-mode
M-x global-auto-revert-mode
M-: (setq global-auto-revert-non-file-buffers t)
M-x buffer-menu

then the fontification of the buffer names disappears after a while
but reappears for a while each time one touches the keyboard (arrow
keys, for instance) or clicks with the mouse.  Then it disappears again.
It gives a flicker effect which is very annoying.  It must be rather
recent or I would have noticed this earlier.

The problem definitely does not occur in a CVS from February 7, 2005,
which I have left around.  Since then, no changes of any substance
occurred to autorevert.el.  (Only doc fixes and similar.)

On the other hand, I understand that several non-trivial changes to
font-lock-mode were made recently.

Sincerely,

Luc.

Re: Problems fontifying an autoreverting Buffer Menu

[Luc Teirlinck]

It turns out that the new buggish behavior of the auto-reverting
Buffer Menu, which I described earlier, is caused by a change made
today, namely making Buffer-menu-buffer-face the value of the
font-lock-face property rather than the face property.  Reverting that
change makes the problem completely go away.  But I presume that there
must have been some good reason for the change.  The change is however
not mentioned in the ChangeLog:

* buff-menu.el (Buffer-menu-buffer-face): In group Buffer-menu.

Which does not say that it is now the value of a different text
property.  It is a non-trivial change, which is very user visible,
especially to users not enabling font-lock-mode by default and a
change which breaks existing code.  So, it should at least be
mentioned in the ChangeLog.

Sincerely,

Luc.

Re: Problems fontifying an autoreverting Buffer Menu

[Richard Stallman]

    Buffer Menu, which I described earlier, is caused by a change made
    today, namely making Buffer-menu-buffer-face the value of the
    font-lock-face property rather than the face property.  Reverting that
    change makes the problem completely go away.  But I presume that there
    must have been some good reason for the change.

The idea was that this would cause highlighting to occur
only when Font-Lock mode is enabled.  That is the new convention:
modes that compute highlighting in a special way do so
by setting the font-lock-face property, and then Font-Lock mode operates
by causing the font-lock-face property to be displayed.

Is any other change needed to make this work right?
The node Precalculated Fontification seems to say no,
but maybe it is inaccurate.

      The change is however
    not mentioned in the ChangeLog:

Sorry, I was in a hurry checking them in, and I didn't notice there
was a second change in the file as well.  I will fix that.

Re: Problems fontifying an autoreverting Buffer Menu

[Luc Teirlinck]

   Is any other change needed to make this work right?
   The node Precalculated Fontification seems to say no,
   but maybe it is inaccurate.

I believe that the extra change needed is to make the global-font-lock-mode
implementation (as well as other global minor modes defined with
`define-global-minor-mode') take timers and processes into account.
Apparently, it can currently not handle those.  The current
implementation relies on the assumption that either find-file-hook or
post-command-hook will always run immediately after a major mode
function (see the comments below).  In the case of timers and
processes (and _maybe_ other cases as well), this can be very false.
If you look at the paragraph I deleted from the comments, you see that
it says that one way to implement things more cleanly would be to have
a "major-mode-hook".  We now have such a hook, `after-change-major-mode-hook'.
I believe that the machinery will, for the time being, still have to 
continue to use the two other hooks in addition to
`after-change-major-mode-hook', because not all major modes use
`run-mode-hooks' or otherwise run `after-change-major-mode-hook' yet.

The two small patches to buff-menu.el and easy-mmode.el solve the
auto-reverting Buffer Menu problem.  The comment changes to
font-core.el explain the rationale.

I can install if desired.

===File ~/buff-menu-diff====================================
*** buff-menu.el	19 May 2005 10:46:32 -0500	1.81
--- buff-menu.el	21 May 2005 16:06:59 -0500	
***************
*** 190,196 ****
         #'(lambda (&optional noconfirm) 'fast))
    (setq truncate-lines t)
    (setq buffer-read-only t)
!   (run-hooks 'buffer-menu-mode-hook))
  
  ;; This function exists so we can make the doc string of Buffer-menu-mode
  ;; look nice.
--- 190,196 ----
         #'(lambda (&optional noconfirm) 'fast))
    (setq truncate-lines t)
    (setq buffer-read-only t)
!   (run-mode-hooks 'buffer-menu-mode-hook))
  
  ;; This function exists so we can make the doc string of Buffer-menu-mode
  ;; look nice.
============================================================

===File ~/easy-mmode-diff===================================
*** easy-mmode.el	17 May 2005 10:08:33 -0500	1.62
--- easy-mmode.el	21 May 2005 19:08:35 -0500	
***************
*** 307,314 ****
--- 307,316 ----
  	 (if ,global-mode
  	     (progn
  	       (add-hook 'find-file-hook ',buffers)
+ 	       (add-hook 'after-change-major-mode-hook ',buffers)
  	       (add-hook 'change-major-mode-hook ',cmmh))
  	   (remove-hook 'find-file-hook ',buffers)
+ 	   (remove-hook 'after-change-major-mode-hook ',buffers)
  	   (remove-hook 'change-major-mode-hook ',cmmh))
  
  	 ;; Go through existing buffers.
============================================================

===File ~/font-core-diff====================================
*** font-core.el	25 Apr 2005 15:51:45 -0500	1.27
--- font-core.el	21 May 2005 17:41:00 -0500	
***************
*** 231,238 ****
  ;; hook is run, the major mode is in the process of being changed and we do not
  ;; know what the final major mode will be.  So, `font-lock-change-major-mode'
  ;; only (a) notes the name of the current buffer, and (b) adds our function
! ;; `turn-on-font-lock-if-enabled' to the hook variables `find-file-hook' and
! ;; `post-command-hook' (for buffers that are not visiting files).  By the time
  ;; the functions on the first of these hooks to be run are run, the new major
  ;; mode is assumed to be in place.  This way we get a Font Lock function run
  ;; when a major mode is turned on, without knowing major modes or their hooks.
--- 231,240 ----
  ;; hook is run, the major mode is in the process of being changed and we do not
  ;; know what the final major mode will be.  So, `font-lock-change-major-mode'
  ;; only (a) notes the name of the current buffer, and (b) adds our function
! ;; `turn-on-font-lock-if-enabled' to the hook variable
! ;; `after-change-major-mode-hook', as well as to the hook variables
! ;; `find-file-hook' and `post-command-hook' (for modes that do not yet
! ;; run `after-change-major-mode-hook').  By the time
  ;; the functions on the first of these hooks to be run are run, the new major
  ;; mode is assumed to be in place.  This way we get a Font Lock function run
  ;; when a major mode is turned on, without knowing major modes or their hooks.
***************
*** 243,254 ****
  ;; finished, whichever the sooner.  Arguably, any major mode that does not
  ;; follow the convension (a) is broken, and I can't think of any reason why (b)
  ;; would not be met (except `gnudoit' on non-files).  However, it is not clean.
- ;;
- ;; Probably the cleanest solution is to have each major mode function run some
- ;; hook, e.g., `major-mode-hook', but maybe implementing that change is
- ;; impractical.  I am personally against making `setq' a macro or be advised,
- ;; or have a special function such as `set-major-mode', but maybe someone can
- ;; come up with another solution?
  
  ;; User interface.
  ;;
--- 245,250 ----
============================================================

Re: Problems fontifying an autoreverting Buffer Menu

[Luc Teirlinck]

Actually, the patch to easy-mmode I proposed earlier had the
disadvantage that things could run twice by being added to two hooks.
I believe that we can entirely rely on post-command-hook for those
modes that do not run `after-change-major-mode-hook' yet.

That would give these alternative patches:

===File ~/easy-mmode-diff===================================
*** easy-mmode.el	17 May 2005 10:08:33 -0500	1.62
--- easy-mmode.el	21 May 2005 19:25:06 -0500	
***************
*** 306,314 ****
  	 ;; Setup hook to handle future mode changes and new buffers.
  	 (if ,global-mode
  	     (progn
! 	       (add-hook 'find-file-hook ',buffers)
  	       (add-hook 'change-major-mode-hook ',cmmh))
! 	   (remove-hook 'find-file-hook ',buffers)
  	   (remove-hook 'change-major-mode-hook ',cmmh))
  
  	 ;; Go through existing buffers.
--- 306,314 ----
  	 ;; Setup hook to handle future mode changes and new buffers.
  	 (if ,global-mode
  	     (progn
! 	       (add-hook 'after-change-major-mode-hook ',buffers)
  	       (add-hook 'change-major-mode-hook ',cmmh))
! 	   (remove-hook 'after-change-major-mode-hook ',buffers)
  	   (remove-hook 'change-major-mode-hook ',cmmh))
  
  	 ;; Go through existing buffers.
============================================================

===File ~/font-core-diff====================================
*** font-core.el	25 Apr 2005 15:51:45 -0500	1.27
--- font-core.el	21 May 2005 19:33:06 -0500	
***************
*** 231,238 ****
  ;; hook is run, the major mode is in the process of being changed and we do not
  ;; know what the final major mode will be.  So, `font-lock-change-major-mode'
  ;; only (a) notes the name of the current buffer, and (b) adds our function
! ;; `turn-on-font-lock-if-enabled' to the hook variables `find-file-hook' and
! ;; `post-command-hook' (for buffers that are not visiting files).  By the time
  ;; the functions on the first of these hooks to be run are run, the new major
  ;; mode is assumed to be in place.  This way we get a Font Lock function run
  ;; when a major mode is turned on, without knowing major modes or their hooks.
--- 231,239 ----
  ;; hook is run, the major mode is in the process of being changed and we do not
  ;; know what the final major mode will be.  So, `font-lock-change-major-mode'
  ;; only (a) notes the name of the current buffer, and (b) adds our function
! ;; `turn-on-font-lock-if-enabled' to the hook variables
! ;; `after-change-major-mode-hook' and `post-command-hook' (for modes
! ;; that do not yet run `after-change-major-mode-hook').  By the time
  ;; the functions on the first of these hooks to be run are run, the new major
  ;; mode is assumed to be in place.  This way we get a Font Lock function run
  ;; when a major mode is turned on, without knowing major modes or their hooks.
***************
*** 243,254 ****
  ;; finished, whichever the sooner.  Arguably, any major mode that does not
  ;; follow the convension (a) is broken, and I can't think of any reason why (b)
  ;; would not be met (except `gnudoit' on non-files).  However, it is not clean.
- ;;
- ;; Probably the cleanest solution is to have each major mode function run some
- ;; hook, e.g., `major-mode-hook', but maybe implementing that change is
- ;; impractical.  I am personally against making `setq' a macro or be advised,
- ;; or have a special function such as `set-major-mode', but maybe someone can
- ;; come up with another solution?
  
  ;; User interface.
  ;;
--- 244,249 ----
============================================================