Re: Problems fontifying an autoreverting Buffer Menu

[Luc Teirlinck <teirllm@dms.auburn.edu>]

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