GNU bug report logs - #2134
[PATCH] progmodes/compile.el: check global-font-lock-mode

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 2134 in the body.
You can then email your comments to 2134 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Jari Aalto <jari.aalto <at> cante.net>
To: submit <at> debbugs.gnu.org
Subject: [PATCH] progmodes/compile.el: check global-font-lock-mode
Date: Sat, 31 Jan 2009 14:34:46 +0200

Tags: patch

Here is patch to not to turn on font-lock unconditionally. Patch is
against Emacs version control tree check out 2009-01-31.

2009-01-31  Jari Aalto  <jari.aalto <at> cante.net>

	* progmodes/compile.el (compilation-start): Run
	`font-lock-fontify-buffer' only if `global-font-lock-mode'
	is non-nil.

From 473ca5257db6da8da4d31e4b9a2682f0972cc8c1 Mon Sep 17 00:00:00 2001
From: Jari Aalto <jari.aalto <at> cante.net>
Date: Sat, 31 Jan 2009 14:27:23 +0200
Subject: [PATCH] lisp/progmodes/compile.el: (compilation-start): check global-font-lock-mode

Signed-off-by: Jari Aalto <jari.aalto <at> cante.net>
---
 lisp/progmodes/compile.el |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/lisp/progmodes/compile.el b/lisp/progmodes/compile.el
index 2554730..1259403 100644
--- a/lisp/progmodes/compile.el
+++ b/lisp/progmodes/compile.el
@@ -1326,7 +1326,8 @@ Returns the compilation buffer created."
 	  ;; Without async subprocesses, the buffer is not yet
 	  ;; fontified, so fontify it now.
 	  (let ((font-lock-verbose nil)) ; shut up font-lock messages
-	    (font-lock-fontify-buffer))
+	    (if global-font-lock-mode
+		(font-lock-fontify-buffer)))
 	  (set-buffer-modified-p nil)
 	  (message "Executing `%s'...done" command)))
       ;; Now finally cd to where the shell started make/grep/...
-- 
1.5.6.5

Message #10 received at 2134 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Jari Aalto <jari.aalto <at> cante.net>
Cc: 2134 <at> debbugs.gnu.org
Subject: Re: bug#2134: [PATCH] progmodes/compile.el: check global-font-lock-mode
Date: Sat, 31 Jan 2009 14:54:15 -0500

> Here is patch to not to turn on font-lock unconditionally. Patch is
> against Emacs version control tree check out 2009-01-31.

If you read the rest of the compile.el code, you'll see that it uses
font-lock to do its job, which is why it's turned on unconditionally.


        Stefan

Message #15 received at 2134 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Jari Aalto <jari.aalto <at> cante.net>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 2134 <at> debbugs.gnu.org
Subject: Re: bug#2134: [PATCH] progmodes/compile.el: check global-font-lock-mode
Date: Sun, 01 Feb 2009 12:46:22 +0200

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>> Here is patch to not to turn on font-lock unconditionally. Patch is
>> against Emacs version control tree check out 2009-01-31.
>
> If you read the rest of the compile.el code, you'll see that it uses
> font-lock to do its job, which is why it's turned on unconditionally.
>

The buffer handling could be improved to work without font lock. In some
cases the colors distract reading; thus font-lock is turned offm, but
RET no longer intreprets the line.

SUGGESTION

There could be be alternative handler to read the current line and
respond to RET (etc.) when font-lock is turned off. I'm supposing here
that standard grep syntax would be easy to handle:

   default-directory: DIR

   FILE:LINE:MATCH

Jari

Message #20 received at 2134 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Richard M Stallman <rms <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>, 2134 <at> debbugs.gnu.org
Cc: jari.aalto <at> cante.net, 2134 <at> debbugs.gnu.org
Subject: Re: bug#2134: [PATCH] progmodes/compile.el: check global-font-lock-mode
Date: Sun, 01 Feb 2009 17:49:07 -0500

    If you read the rest of the compile.el code, you'll see that it uses
    font-lock to do its job, which is why it's turned on unconditionally.

What's happening here is not clean.  Yes, compile.el needs to force
the Font Lock mechanism to work, all the time; but it should not show
the faces on the screen if the user disables Font Lock mode.

What this calls for is something like font-lock-syntactic-keywords.
Or a switch in Font Lock to say, "Unconditionally activate the Font
Lock mechanism, independent of whether Font Lock mode is enabled, but
store the faces in the `font-lock-face' property."  With that, the
mechanism will always find the errors, but the user can control
whether to display the highlighting.

Message #27 received at 2134 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Jari Aalto <jari.aalto <at> cante.net>
Cc: 2134 <at> debbugs.gnu.org
Subject: Re: bug#2134: [PATCH] progmodes/compile.el: check global-font-lock-mode
Date: Sun, 01 Feb 2009 17:54:47 -0500

>>> Here is patch to not to turn on font-lock unconditionally. Patch is
>>> against Emacs version control tree check out 2009-01-31.
>> 
>> If you read the rest of the compile.el code, you'll see that it uses
>> font-lock to do its job, which is why it's turned on unconditionally.

> The buffer handling could be improved to work without font lock. In some

Yes, we indeed want that.  Patches welcome.

The way it could work (most likely) is by not hooking directly into
font-lock but using after-change-functions instead (and then probably
call font-lock-fontify-region (or somesuch function) from it), and only
set the `font-lock-face' property rather than `face'.

Another way to do that, would be to change font-lock-mode to allow
"invisible" activation such that `font-lock-face' is not remapped to
`face' and such that font-lock keywords end up adding entries to
`font-lock-face' rather than to `face', so that the user can later on
turn on font-lock-mode (in normal mode) at which point all the faces
would be activated.  That would be better.


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.