* Re: Problems fontifying an autoreverting Buffer Menu
2005-05-21 4:46 ` Richard Stallman
@ 2005-05-22 0:35 ` Luc Teirlinck
2005-05-22 0:49 ` Luc Teirlinck
1 sibling, 0 replies; 5+ messages in thread
From: Luc Teirlinck @ 2005-05-22 0:35 UTC (permalink / raw)
Cc: emacs-devel
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 ----
============================================================
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Problems fontifying an autoreverting Buffer Menu
2005-05-21 4:46 ` Richard Stallman
2005-05-22 0:35 ` Luc Teirlinck
@ 2005-05-22 0:49 ` Luc Teirlinck
1 sibling, 0 replies; 5+ messages in thread
From: Luc Teirlinck @ 2005-05-22 0:49 UTC (permalink / raw)
Cc: emacs-devel
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 ----
============================================================
^ permalink raw reply [flat|nested] 5+ messages in thread