Re: bug in hi-lock?

[Alan Mackenzie <acm@muc.de>]

Hi, Dale!

On Wed, May 20, 2009 at 11:32:08AM -0500, Dale Schaafsma wrote:
> Hi Alan,
>   I've attached a small text file...my regex is foo...and I just hit return
> to take the default color of hi-yellow.
>   Thanks for the compliment on the bug report (I do write&debug software so
> I've tried to be specific!)...should I send this message to the address
> below?

Thanks for the file.  It was ideal.

Now, take a deep, deep, breath.  This is what's happening:

The bug, (switching hi-lock-mode off) has nothing to do with
global-hi-lock-mode, it also happens when you manually switch on
hi-lock-mode.

The bug happens only the first time you do C-x w h inside a buffer.  If
you then switch hi-lock-mode on again manually, it stays on.

The bug happens only in major modes which don't have any font-lock
keywords defined.  Text mode is one such mode.

The bug happens only in major modes which don't have font-lock-keywords
defined.  Text mode is one such mode.

This is the sequence of events in foo.text:

(i) C-x w h foo filters through to ...
(ii) hi-lock-set-pattern which calls ...
(iii) font-lock-add-keywords.  This function notices that
  font-lock-keywords is nil (more or less), and thus decides that, and I
  quote:

     ;; The major mode has not set any keywords, so when we enabled
     ;; font-lock-mode it only enabled the font-core.el part, not the
     ;; font-lock-mode-internal.  Try again.
  
(iv) font-lock-add-keywords, rather than carefully and conservatively
  performing the remaining initialisation, brutally and recursively
  power cycles font-lock mode thusly:

           (font-lock-mode -1)
           (set (make-local-variable 'font-lock-defaults) '(nil t))
           (font-lock-mode 1))

(v) The first of these invocations runs a hook called (something like)
  `font-lock-mode-off-hook' whose value is `hi-lock-font-lock-hook'.
(vi) hi-lock-font-lock-hook, on being told that font-lock-mode has been
  switched off invokes `(hi-lock-mode -1)'.

If I were to assign guilt for this bug, it would be to the scrappy way
font-lock-mode is power cycled.

However: The good news is that the bug has been fixed for Emacs 23 (I'm
not sure how, but I vaguely remember complaining about something similar
~2 years ago, and something got fixed).

How about a workaround?  I haven't tested this, but something like this
function:

(defun ds-protect-hl ()
  "Prevent Font Lock Mode switching off hi-lock-mode at first use."
  (make-local-variable 'font-lock-defaults)
  (unless font-lock-defaults
    (if font-lock-mode
        (progn
          (font-lock-mode -1)
          (setq font-lock-defaults) '(nil t))
          (font-lock-mode 1))
      (setq font-lock-defaults '(nil t)))))

, if placed on an appropriate hook (?after-change-major-mode-hook,
perhaps) might do the job.  On the other hand, it might also screw up
font-lock-mode.

[Note: that's just an idea, not a working function.]

-- 
Alan Mackenzie (Nuremberg, Germany).