* bug in hi-lock? @ 2009-05-19 20:16 Dale 2009-05-20 7:06 ` Alan Mackenzie 0 siblings, 1 reply; 6+ messages in thread From: Dale @ 2009-05-19 20:16 UTC (permalink / raw) To: help-gnu-emacs 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: bug in hi-lock? 2009-05-19 20:16 bug in hi-lock? Dale @ 2009-05-20 7:06 ` Alan Mackenzie 2009-05-20 16:32 ` Dale Schaafsma 0 siblings, 1 reply; 6+ messages in thread From: Alan Mackenzie @ 2009-05-20 7:06 UTC (permalink / raw) To: Dale; +Cc: help-gnu-emacs 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). ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: bug in hi-lock? 2009-05-20 7:06 ` Alan Mackenzie @ 2009-05-20 16:32 ` Dale Schaafsma 2009-05-21 19:02 ` Alan Mackenzie 0 siblings, 1 reply; 6+ messages in thread From: Dale Schaafsma @ 2009-05-20 16:32 UTC (permalink / raw) To: Alan Mackenzie; +Cc: help-gnu-emacs [-- 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: bug in hi-lock? 2009-05-20 16:32 ` Dale Schaafsma @ 2009-05-21 19:02 ` Alan Mackenzie 2009-05-23 9:07 ` Alan Mackenzie 2009-06-04 19:32 ` Dale Schaafsma 0 siblings, 2 replies; 6+ messages in thread From: Alan Mackenzie @ 2009-05-21 19:02 UTC (permalink / raw) To: Dale Schaafsma; +Cc: help-gnu-emacs 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). ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: bug in hi-lock? 2009-05-21 19:02 ` Alan Mackenzie @ 2009-05-23 9:07 ` Alan Mackenzie 2009-06-04 19:32 ` Dale Schaafsma 1 sibling, 0 replies; 6+ messages in thread From: Alan Mackenzie @ 2009-05-23 9:07 UTC (permalink / raw) To: Dale Schaafsma; +Cc: help-gnu-emacs 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). ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: bug in hi-lock? 2009-05-21 19:02 ` Alan Mackenzie 2009-05-23 9:07 ` Alan Mackenzie @ 2009-06-04 19:32 ` Dale Schaafsma 1 sibling, 0 replies; 6+ messages in thread From: Dale Schaafsma @ 2009-06-04 19:32 UTC (permalink / raw) To: Alan Mackenzie; +Cc: help-gnu-emacs [-- 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 --] ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2009-06-04 19:32 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2009-05-19 20:16 bug in hi-lock? Dale 2009-05-20 7:06 ` Alan Mackenzie 2009-05-20 16:32 ` Dale Schaafsma 2009-05-21 19:02 ` Alan Mackenzie 2009-05-23 9:07 ` Alan Mackenzie 2009-06-04 19:32 ` Dale Schaafsma
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.