From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dale Schaafsma Newsgroups: gmane.emacs.help Subject: Re: bug in hi-lock? Date: Thu, 4 Jun 2009 14:32:49 -0500 Message-ID: References: <11e22679-5000-411a-9092-91e01436cb80@o30g2000vbc.googlegroups.com> <20090520070644.GA1353@muc.de> <20090521190248.GD1392@muc.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=0015175cb888612ef1046b8ad7a9 X-Trace: ger.gmane.org 1244166488 13734 80.91.229.12 (5 Jun 2009 01:48:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 5 Jun 2009 01:48:08 +0000 (UTC) Cc: help-gnu-emacs@gnu.org To: Alan Mackenzie Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri Jun 05 03:48:06 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 1MCOXM-0003kX-Pp for geh-help-gnu-emacs@m.gmane.org; Fri, 05 Jun 2009 03:48:05 +0200 Original-Received: from localhost ([127.0.0.1]:60809 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MCOXL-00088x-Jh for geh-help-gnu-emacs@m.gmane.org; Thu, 04 Jun 2009 21:48:03 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MCNKQ-0004IN-Nl for help-gnu-emacs@gnu.org; Thu, 04 Jun 2009 20:30:38 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MCNKP-0004Hh-Ub for help-gnu-emacs@gnu.org; Thu, 04 Jun 2009 20:30:38 -0400 Original-Received: from [199.232.76.173] (port=52860 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MCMRV-0006wb-4f for help-gnu-emacs@gnu.org; Thu, 04 Jun 2009 19:33:54 -0400 Original-Received: from mx20.gnu.org ([199.232.41.8]:38232) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MCIgF-00029w-Tz for help-gnu-emacs@gnu.org; Thu, 04 Jun 2009 15:32:52 -0400 Original-Received: from qw-out-1920.google.com ([74.125.92.147]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MCIgE-0006Oz-Us for help-gnu-emacs@gnu.org; Thu, 04 Jun 2009 15:32:51 -0400 Original-Received: by qw-out-1920.google.com with SMTP id 4so593182qwk.24 for ; Thu, 04 Jun 2009 12:32:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=L/Iyls9nk0b/z2osN7gDr7stQLcH931zHtDy5hL5nCc=; b=rcDWFFkJkGWtSl3vliZAyVf5DXKgKV3gYDTSH/tQ+lopvknbbFCNE7uXJqg4z12NAE d5v4U18klhWCo/jN7Z6QSQTlvge4mnpOv5pOG4eVv2LLeVsgIcPH+5zUdVywi/RaptbA ILbqOwap6h8Y+WQeqmaU+IVp0xUAQbwizQE14= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=uHb1B+pQDd3Mh8D517K0Lo73QvaVg28U9uXPxzerr80sF+QAoIlbubCSQfSRsJjeEC 1OgFoCijizFLE2Ja1qC8ez99DCb4NNdi+1TVYkib1l/kDTa6ZhdCgoeg4i98jtiyJXsO i1YSX1kTF1QYVlVczwiTVEYmwUauDpOizVAkU= Original-Received: by 10.224.67.130 with SMTP id r2mr2746458qai.281.1244143969969; Thu, 04 Jun 2009 12:32:49 -0700 (PDT) In-Reply-To: <20090521190248.GD1392@muc.de> X-Detected-Operating-System: by mx20.gnu.org: GNU/Linux 2.6 (newer, 2) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) 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:64952 Archived-At: --0015175cb888612ef1046b8ad7a9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 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). > --0015175cb888612ef1046b8ad7a9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Alan,
=A0 Thanks for the workaround...yep that works like a charm.=A0 Glad that it is fixed in emacs 23...I'll have to give that a whirl= sometime soon.
Thanks again,
=A0Dale

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,
> =A0 I've attached a small text file...my regex is foo...and I just= hit return
> to take the default color of hi-yellow.
> =A0 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 ad= dress
> below?

Thanks for the file. =A0It was ideal.

Now, take a deep, deep, breath. =A0This 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. =A0If 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. =A0Text mode is one such mode.

The bug happens only in major modes which don't have font-lock-keywords=
defined. =A0Text 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. =A0This function notices that
=A0font-lock-keywords is nil (more or less), and thus decides that, and I<= br> =A0quote:

=A0 =A0 ;; The major mode has not set any keywords, so when we enabled
=A0 =A0 ;; font-lock-mode it only enabled the font-core.el part, not the =A0 =A0 ;; font-lock-mode-internal. =A0Try again.

(iv) font-lock-add-keywords, rather than carefully and conservatively
=A0performing the remaining initialisation, brutally and recursively
=A0power cycles font-lock mode thusly:

=A0 =A0 =A0 =A0 =A0 (font-lock-mode -1)
=A0 =A0 =A0 =A0 =A0 (set (make-local-variable 'font-lock-defaults) = 9;(nil t))
=A0 =A0 =A0 =A0 =A0 (font-lock-mode 1))

(v) The first of these invocations runs a hook called (something like)
=A0`font-lock-mode-off-hook' whose value is `hi-lock-font-lock-hook= 9;.
(vi) hi-lock-font-lock-hook, on being told that font-lock-mode has been
=A0switched 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? =A0I haven't tested this, but something like th= is
function:

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

, if placed on an appropriate hook (?after-change-major-mode-hook,
perhaps) might do the job. =A0On 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).

--0015175cb888612ef1046b8ad7a9--