From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: hi-lock-mode doesn't work with emacs -Q. Date: Sat, 16 Jun 2007 00:04:52 +0100 Message-ID: <20070615230452.GB3496@muc.de> References: <20070607092651.GA1710@muc.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1181943543 19265 80.91.229.12 (15 Jun 2007 21:39:03 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 15 Jun 2007 21:39:03 +0000 (UTC) Cc: David Koppelman , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jun 15 23:39:01 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1HzJVU-000380-Cu for ged-emacs-devel@m.gmane.org; Fri, 15 Jun 2007 23:39:00 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HzJVT-0006ns-EZ for ged-emacs-devel@m.gmane.org; Fri, 15 Jun 2007 17:38:59 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HzJVQ-0006mI-1c for emacs-devel@gnu.org; Fri, 15 Jun 2007 17:38:56 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HzJVP-0006lq-EV for emacs-devel@gnu.org; Fri, 15 Jun 2007 17:38:55 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HzJVP-0006lj-Bi for emacs-devel@gnu.org; Fri, 15 Jun 2007 17:38:55 -0400 Original-Received: from colin.muc.de ([193.149.48.1] 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 1HzJVO-000641-Pd for emacs-devel@gnu.org; Fri, 15 Jun 2007 17:38:55 -0400 Original-Received: (qmail 42626 invoked by uid 3782); 15 Jun 2007 21:38:53 -0000 Original-Received: from acm.muc.de (p54A3EAD8.dip.t-dialin.net [84.163.234.216]) by colin2.muc.de (tmda-ofmipd) with ESMTP; Fri, 15 Jun 2007 23:38:50 +0200 Original-Received: (qmail 4564 invoked by uid 1000); 15 Jun 2007 23:04:52 -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-kernel: FreeBSD 4.6-4.9 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:73013 Archived-At: Hi, Stefan! On Mon, Jun 11, 2007 at 04:25:14PM -0400, Stefan Monnier wrote: > > . Enable hi-lock-mode and make "foo" a highlightable pattern: > > M-x hi-lock-mode > > C-x w h foo ; accept the default hi-yellow face. > > . This highlights the "foo" yellow, as expected. At the end of the > > line, type: > > foo > > . This new "foo" doesn't get highlighted. It should be. > I believe the patch below fixes the problem without making things worse > and without requiring changes to hi-lock.el. > Stefan > --- font-lock.el 08 May 2007 11:55:52 -0400 1.317 > +++ font-lock.el 11 Jun 2007 15:56:01 -0400 > @@ -698,6 +698,14 @@ > ;; contain the new keywords. > (font-lock-update-removed-keyword-alist mode keywords how)) > (t > + (when (and font-lock-mode > + (not (or font-lock-keywords font-lock-defaults))) > + ;; 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. > + (font-lock-mode -1) > + (set (make-local-variable 'font-lock-defaults) '(nil t)) > + (font-lock-mode 1)) > ;; Otherwise set or add the keywords now. > ;; This is a no-op if it has been done already in this buffer > ;; for the correct major mode. That patch will certainly make hi-lock work properly. However, are you sure there is nothing else which can necessitate the enabling of the after-change function? Also, there is nothing in the documentation forbidding a hacker from changing font-lock-keywords directly, which would cause font-lock to fail in other circumstances. My first thought was that instead of switching Font Lock fully off then fully on again, as you are proposing in your patch, we should just call font-lock-mode-internal. But this clashes with the font-lock-default-function mechanism - font-lock-keywords cannot know that the current f-l-default-function has used this "ignition/starter-motor" mechanism. It seems to me that this two-stage initialisation of f-l-mode brings a lot of complexity for very little gain - The f-l-change-function can never execute in the background and consume vast amounts of CPU usage. It can only ever be called for the current buffer, and if Font Lock is enabled, yet f-l-keywords hasn't been set, its runtime is negligible anyway. Or is there some good reason for this optimisation that I'm missing? If not, I suggest that you simply remove this optimisation and always install the after-change function when f-l-mode is started. -- Alan.