help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bug in hi-lock?


From: Dale Schaafsma
Subject: Re: bug in hi-lock?
Date: Thu, 4 Jun 2009 14:32:49 -0500

Hi Alan,
  Thanks for the workaround...yep that works like a charm.
  Glad that it is fixed in emacs 23...I'll have to give that a whirl sometime soon.
Thanks again,
 Dale

On Thu, May 21, 2009 at 2:02 PM, Alan Mackenzie <acm@muc.de> wrote:
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).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]