From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.help Subject: Re: bug in hi-lock? Date: Thu, 21 May 2009 19:02:48 +0000 Message-ID: <20090521190248.GD1392@muc.de> References: <11e22679-5000-411a-9092-91e01436cb80@o30g2000vbc.googlegroups.com> <20090520070644.GA1353@muc.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1242932565 7773 80.91.229.12 (21 May 2009 19:02:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 21 May 2009 19:02:45 +0000 (UTC) Cc: help-gnu-emacs@gnu.org To: Dale Schaafsma Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Thu May 21 21:02:38 2009 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1M7DXF-00081n-Rc for geh-help-gnu-emacs@m.gmane.org; Thu, 21 May 2009 21:02:34 +0200 Original-Received: from localhost ([127.0.0.1]:47838 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M7DXF-00024V-Ei for geh-help-gnu-emacs@m.gmane.org; Thu, 21 May 2009 15:02:33 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M7DWu-000249-9a for help-gnu-emacs@gnu.org; Thu, 21 May 2009 15:02:12 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M7DWo-000234-NP for help-gnu-emacs@gnu.org; Thu, 21 May 2009 15:02:10 -0400 Original-Received: from [199.232.76.173] (port=60170 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M7DWo-000231-K7 for help-gnu-emacs@gnu.org; Thu, 21 May 2009 15:02:06 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:1971 helo=mail.muc.de) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1M7DWn-0001Gd-St for help-gnu-emacs@gnu.org; Thu, 21 May 2009 15:02:06 -0400 Original-Received: (qmail 15510 invoked by uid 3782); 21 May 2009 19:02:02 -0000 Original-Received: from acm.muc.de (pD9E23190.dip.t-dialin.net [217.226.49.144]) by colin2.muc.de (tmda-ofmipd) with ESMTP; Thu, 21 May 2009 21:01:59 +0200 Original-Received: (qmail 11073 invoked by uid 1000); 21 May 2009 19:02:48 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Delivery-Agent: TMDA/1.1.5 (Fettercairn) X-Primary-Address: acm@muc.de X-detected-operating-system: by monty-python.gnu.org: FreeBSD 4.6-4.9 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:64614 Archived-At: 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).