bug in hi-lock?

bug in hi-lock?

[Dale]

Hi All, not sure where to issue potential bug reports. Apologies if
I'm in the wrong place.
I'm running GNU Emacs 22.3.1 (i386-mingw-nt5.1.2600)

Running the following scenario caused hi-lock to automatically disable
for me.
emacs -Q
M-x eval-expression
(global-hi-lock-mode 1)
;; load a file at this point
C-x w h
;; type in my regex, and it is successfully highlighted after picking
my color

;; the second instantiation of the command causes issues
C-x w   ;; results in "C-x w is undefined" in the message bar.

 Has anyone else seen this? or am I doing something incorrectly?

Thanks,
 Dale

Re: bug in hi-lock?

[Alan Mackenzie]

Hi, Dale!

On Tue, May 19, 2009 at 01:16:46PM -0700, Dale wrote:
> Hi All, not sure where to issue potential bug reports. Apologies if
> I'm in the wrong place.

bug-gnu-emacs@gnu.org is the bug place, but no worries!

> I'm running GNU Emacs 22.3.1 (i386-mingw-nt5.1.2600)

> Running the following scenario caused hi-lock to automatically disable
> for me.
> emacs -Q
> M-x eval-expression
> (global-hi-lock-mode 1)
> ;; load a file at this point
> C-x w h
> ;; type in my regex, and it is successfully highlighted after picking
> my color

> ;; the second instantiation of the command causes issues
> C-x w   ;; results in "C-x w is undefined" in the message bar.

>  Has anyone else seen this? or am I doing something incorrectly?

Yes, this has happened to me sporadically, and it's irritated me
something rotten.  It's been one of these things which isn't quite bad
enough to warrant full-scale debugging, yet bad enough to irk.  ;-)

Trouble is, I can't now reproduce it now with your recipe (above).  ;-(

From the way you describe it, I'm assuming that you can make the bug
happen repeatedly.  The only thing you haven't specified precisely above
is what file you're loading and what regexp you type.  (In general, a
brilliant bug report, by the way.)

Any chance you could supply the file and state the regexp?  Best would
be if you could include a small source file in your post, or give the
name of, say, an Emacs source file.

> Thanks,
>  Dale

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: bug in hi-lock?

[Dale Schaafsma]

[-- Attachment #1.1: Type: text/plain, Size: 1944 bytes --]

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,
 Dale

On Wed, May 20, 2009 at 2:06 AM, Alan Mackenzie <acm@muc.de> wrote:

> Hi, Dale!
>
> On Tue, May 19, 2009 at 01:16:46PM -0700, Dale wrote:
> > Hi All, not sure where to issue potential bug reports. Apologies if
> > I'm in the wrong place.
>
> bug-gnu-emacs@gnu.org is the bug place, but no worries!
>
> > I'm running GNU Emacs 22.3.1 (i386-mingw-nt5.1.2600)
>
> > Running the following scenario caused hi-lock to automatically disable
> > for me.
> > emacs -Q
> > M-x eval-expression
> > (global-hi-lock-mode 1)
> > ;; load a file at this point
> > C-x w h
> > ;; type in my regex, and it is successfully highlighted after picking
> > my color
>
> > ;; the second instantiation of the command causes issues
> > C-x w   ;; results in "C-x w is undefined" in the message bar.
>
> >  Has anyone else seen this? or am I doing something incorrectly?
>
> Yes, this has happened to me sporadically, and it's irritated me
> something rotten.  It's been one of these things which isn't quite bad
> enough to warrant full-scale debugging, yet bad enough to irk.  ;-)
>
> Trouble is, I can't now reproduce it now with your recipe (above).  ;-(
>
> From the way you describe it, I'm assuming that you can make the bug
> happen repeatedly.  The only thing you haven't specified precisely above
> is what file you're loading and what regexp you type.  (In general, a
> brilliant bug report, by the way.)
>
> Any chance you could supply the file and state the regexp?  Best would
> be if you could include a small source file in your post, or give the
> name of, say, an Emacs source file.
>
> > Thanks,
> >  Dale
>
> --
> Alan Mackenzie (Nuremberg, Germany).
>

[-- Attachment #1.2: Type: text/html, Size: 2538 bytes --]

[-- Attachment #2: foo.txt --]
[-- Type: text/plain, Size: 537 bytes --]

;; This buffer is for notes you don't want to save, and for Lisp evaluation.
;; If you want to create a file, visit that file with C-x C-f,
;; then enter the text in that file's own buffer.

;; regex used: foo

foo this is a foo that jumped over the foo
the quick brown fox jumped over the lazy dog
Now is the time for all good men to come to the aid of the party
The quick onyx goblin jumps over the lazy dwarf
Now is the time for all good men to come to the aid of their country.
foo this is a foo that jumped over the foo

Re: bug in hi-lock?

[Alan Mackenzie]

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).

Re: bug in hi-lock?

[Alan Mackenzie]

Hi again, Dale!

On Thu, May 21, 2009 at 07:02:48PM +0000, Alan Mackenzie 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:

[ snip diagnosis: summary - Font Lock Mode and Hi-Lock Mode get their
mutual nickers in a twist at the very first C-x w h in a buffer where
font-lock-keywords starts off nil. ]

Here's a proper workaround:  Put the following early on in your .emacs:

   (setq-default font-lock-keywords "\\<\\>")

[The string is a regexp which matches somewhere at both the start and end
of a word, i.e. nowhere at all.]

Thanks for goading me into finally tracking this down!

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: bug in hi-lock?

[Dale Schaafsma]

[-- Attachment #1: Type: text/plain, Size: 3325 bytes --]

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).
>

[-- Attachment #2: Type: text/html, Size: 4016 bytes --]