GNU bug report logs - #7771
23.1; can't turn off font-lock-mode globally

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 7771 in the body.
You can then email your comments to 7771 AT debbugs.gnu.org in the normal way.

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

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "K. Richard Pixley" <rich <at> noir.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 23.1; can't turn off font-lock-mode globally
Date: Sun, 02 Jan 2011 11:17:33 -0800

I find font-lock modes to be illegible and highly annoying.  And I
can't seem to find a way to turn them off, completely, across the
board, entirely, throughout my emacs.

(global-font-lock-mode 0) doesn't seem to work.  I have it in my
.emacs.el and I'm setting it manually and still when I visit a new
file, or any of a number of popup buffers arrive, they still have
illegible font-lock color settings.

If there is a way, I should be able to find it either from a search
for "font-lock" on the info page or through M-x apropos font-lock.

If there is no simple way to turn it off, then that is a bug.

(I'm reporting on emacs from ubuntu-10.10 amd64 server, but I have the
same problem on many other versions.)


In GNU Emacs 23.1.1 (x86_64-pc-linux-gnu, GTK+ Version 2.20.0)
 of 2010-03-29 on yellow, modified by Debian
Windowing system distributor `The X.Org Foundation', version 11.0.10402000
configured using `configure  '--build=x86_64-linux-gnu' 
'--host=x86_64-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib' 
'--libexecdir=/usr/lib' '--localstatedir=/var/lib' 
'--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes' 
'--enable-locallisppath=/etc/emacs23:/etc/emacs:/usr/local/share/emacs/23.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/23.1/site-lisp:/usr/share/emacs/site-lisp:/usr/share/emacs/23.1/leim' 
'--with-x=yes' '--with-x-toolkit=gtk' '--with-toolkit-scroll-bars' 
'build_alias=x86_64-linux-gnu' 'host_alias=x86_64-linux-gnu' 
'CFLAGS=-DDEBIAN -g -O2' 'LDFLAGS=-g' 'CPPFLAGS=''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default-enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  diff-auto-refine-mode: t
  display-time-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  blink-cursor-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
l f ) <down-mouse-1> <mouse-1> <backspace> , SPC b
l o c k ) : <return> r e t u r n SPC s e l f . u n
p a c k _ f r o m ( b l o c k ) C-n C-n C-u C-x s M-x
c o m p i l e <return> <return> C-x 0 C-x 2 C-x b <return>
M-< C-s s i z e C-p C-a C-x C-t C-x o C-x c y C-v C-p
C-p C-p C-p C-p <help-echo> <down-mouse-1> <mouse-1>
<help-echo> <help-echo> C-x o C-p C-x C-t C-x c y C-M-v
<down-mouse-1> <mouse-1> C-p C-p C-p C-p C-p C-a C-p
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-o C-o <tab> s
i z e SPC = SPC c l a s s m e t h o d ( s i z e ) C-p
C-p C-p C-p C-p C-p C-p C-a C-p C-k C-k C-x c y C-x
o C-v C-x o <help-echo> <down-mouse-1> <mouse-1> C-a
C-k C-k C-n C-n C-n C-n C-n C-n C-n M-f M-f M-b p r
o p e r t y ( C-e ) C-x c y C-x 0 C-x b <return> M-b
M-b M-t C-x c y C-x 0 M-> <help-echo> <down-mouse-1>
<mouse-1> C-u C-x s <down-mouse-1> <mouse-1> C-x C-f
<backspace> <backspace> <backspace> <backspace> <backspace>
<backspace> <backspace> <backspace> <backspace> <backspace>
<backspace> <backspace> <backspace> <backspace> <backspace>
<backspace> <backspace> . e m a c s . e l <return>
C-v M-> <return> C-y C-p C-k C-k <backspace> M-< C-n
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n
C-n C-n C-n C-n C-y C-o C-u C-x s <down-mouse-1> <mouse-1>
M-x r e p o r t - e m a c s - b u g <return>

Recent messages:
Compilation exited abnormally with code 2
Saving file /home/rich/projects/elffile/elffile.py...
Wrote /home/rich/projects/elffile/elffile.py
Compilation exited abnormally with code 2
Mark set
(No files need saving)
Loading vc-svn...done
Mark set [4 times]
Saving file /home/rich/.emacs.el...
Wrote /home/rich/.emacs.el

Message #8 received at 7771 <at> debbugs.gnu.org (full text, mbox):

From: Leo <sdl.web <at> gmail.com>
To: "K. Richard Pixley" <rich <at> noir.com>
Cc: 7771 <at> debbugs.gnu.org
Subject: Re: bug#7771: 23.1; can't turn off font-lock-mode globally
Date: Sun, 02 Jan 2011 22:56:39 +0000

On 2011-01-02 19:17 +0000, K. Richard Pixley wrote:
> (global-font-lock-mode 0) doesn't seem to work. I have it in my
> .emacs.el and I'm setting it manually and still when I visit a new
> file, or any of a number of popup buffers arrive, they still have
> illegible font-lock color settings.

What about (global-font-lock-mode -1)?

Leo

-- 
Oracle is the new evil

Message #11 received at 7771 <at> debbugs.gnu.org (full text, mbox):

From: "K. Richard Pixley" <rich <at> noir.com>
To: Leo <sdl.web <at> gmail.com>
Cc: 7771 <at> debbugs.gnu.org
Subject: Re: bug#7771: 23.1; can't turn off font-lock-mode globally
Date: Sun, 02 Jan 2011 15:19:33 -0800

On 20110102 14:56, Leo wrote:
> On 2011-01-02 19:17 +0000, K. Richard Pixley wrote:
>> (global-font-lock-mode 0) doesn't seem to work. I have it in my
>> .emacs.el and I'm setting it manually and still when I visit a new
>> file, or any of a number of popup buffers arrive, they still have
>> illegible font-lock color settings.
> What about (global-font-lock-mode -1)?
Doesn't appear to be any different than (global-font-lock-mode 0).

--rich

Message #14 received at 7771 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: "K. Richard Pixley" <rich <at> noir.com>
Cc: 7771 <at> debbugs.gnu.org
Subject: Re: bug#7771: 23.1; can't turn off font-lock-mode globally
Date: Sun, 02 Jan 2011 18:49:31 -0500

> (global-font-lock-mode 0) doesn't seem to work.

It should work.  So please tell us the cases where it doesn't work, so
we can try and figure out where's the problem.


        Stefan

Message #17 received at 7771 <at> debbugs.gnu.org (full text, mbox):

From: "K. Richard Pixley" <rich <at> noir.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 7771 <at> debbugs.gnu.org
Subject: Re: bug#7771: 23.1; can't turn off font-lock-mode globally
Date: Sun, 02 Jan 2011 17:20:06 -0800

On 20110102 15:49, Stefan Monnier wrote:
>> (global-font-lock-mode 0) doesn't seem to work.
> It should work.  So please tell us the cases where it doesn't work, so
> we can try and figure out where's the problem.
After starting emacs with "emacs -q", call (global-font-lock-mode 0) by 
hand, then visit a python file.  For me, it is font-locked.

When I call (global-font-lock-mode 0) in my .emacs.el, python mode isn't 
font locked.  But if I ever M-x python-shell, then files visited 
afterward will be font locked, even though global-ton-lock-mode's value 
is nil.  At this point I have to restart emacs in order to see anything.

--rich

Message #20 received at 7771 <at> debbugs.gnu.org (full text, mbox):

From: "K. Richard Pixley" <rich <at> noir.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 7771 <at> debbugs.gnu.org
Subject: Re: bug#7771: 23.1; can't turn off font-lock-mode globally
Date: Sun, 02 Jan 2011 16:29:03 -0800

On 20110102 15:49, Stefan Monnier wrote:
>> (global-font-lock-mode 0) doesn't seem to work.
> It should work.  So please tell us the cases where it doesn't work, so
> we can try and figure out where's the problem.
M-x compile

--rich

Message #26 received at 7771 <at> debbugs.gnu.org (full text, mbox):

From: "K. Richard Pixley" <rich <at> noir.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 7771 <at> debbugs.gnu.org
Subject: Re: bug#7771: 23.1; can't turn off font-lock-mode globally
Date: Sun, 02 Jan 2011 16:27:55 -0800

On 20110102 15:49, Stefan Monnier wrote:
>> (global-font-lock-mode 0) doesn't seem to work.
> It should work.  So please tell us the cases where it doesn't work, so
> we can try and figure out where's the problem.
M-x grep

--rich

Message #31 received at 7771 <at> debbugs.gnu.org (full text, mbox):

From: "K. Richard Pixley" <rich <at> noir.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 7771 <at> debbugs.gnu.org
Subject: Re: bug#7771: 23.1; can't turn off font-lock-mode globally
Date: Sun, 02 Jan 2011 16:31:02 -0800

On 20110102 15:49, Stefan Monnier wrote:
>> (global-font-lock-mode 0) doesn't seem to work.
> It should work.  So please tell us the cases where it doesn't work, so
> we can try and figure out where's the problem.
Visit a binary file, the nonprintable ascii is colored.

--rich

Message #34 received at 7771 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: 7771 <at> debbugs.gnu.org
Subject: Re: bug#7771: 23.1; can't turn off font-lock-mode globally
Date: Sun, 02 Jan 2011 20:54:09 -0500

"K. Richard Pixley" wrote:

> When I call (global-font-lock-mode 0) in my .emacs.el, python mode
> isn't font locked.  But if I ever M-x python-shell, then files visited
> afterward will be font locked, even though global-ton-lock-mode's
> value is nil.

Dupe of http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3628

Message #37 received at 7771 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: 7771 <at> debbugs.gnu.org
Subject: Re: bug#7771: 23.1; can't turn off font-lock-mode globally
Date: Sun, 02 Jan 2011 20:55:17 -0500

"K. Richard Pixley" wrote:

> M-x compile

Dupe of http://debbugs.gnu.org/cgi/bugreport.cgi?bug=801

compile (and grep) require font-lock to work.

Message #42 received at 7771 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: 7771 <at> debbugs.gnu.org
Subject: Re: bug#7771: 23.1; can't turn off font-lock-mode globally
Date: Sun, 2 Jan 2011 21:08:40 -0500

Glenn Morris wrote (on Sun, 2 Jan 2011 at 20:54 -0500):

> Dupe of http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3628

Well, dupe-ish, perhaps.

Message #45 received at 7771 <at> debbugs.gnu.org (full text, mbox):

From: Lennart Borgman <lennart.borgman <at> gmail.com>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 7771 <at> debbugs.gnu.org
Subject: Re: bug#7771: 23.1; can't turn off font-lock-mode globally
Date: Mon, 3 Jan 2011 04:21:38 +0100

On Mon, Jan 3, 2011 at 2:55 AM, Glenn Morris <rgm <at> gnu.org> wrote:
> "K. Richard Pixley" wrote:
>
>> M-x compile
>
> Dupe of http://debbugs.gnu.org/cgi/bugreport.cgi?bug=801
>
> compile (and grep) require font-lock to work.


Richard, if you do not like the colors you can of course customize them.

Message #48 received at 7771 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: "K. Richard Pixley" <rich <at> noir.com>
Cc: 7771 <at> debbugs.gnu.org
Subject: Re: bug#7771: 23.1; can't turn off font-lock-mode globally
Date: Sun, 02 Jan 2011 22:55:52 -0500

close 3628
thanks

>>> (global-font-lock-mode 0) doesn't seem to work.
>> It should work.  So please tell us the cases where it doesn't work, so
>> we can try and figure out where's the problem.
> M-x grep

OK, that one is a known problem: compile.el (used for M-x compile and
M-x grep) uses font-lock internally, so it forces font-lock to
be enabled.

> When I call (global-font-lock-mode 0) in my .emacs.el, python mode isn't
> font locked.  But if I ever M-x python-shell, then files visited afterward
> will be font locked, even though global-ton-lock-mode's value is nil.
> At this point I have to restart emacs in order to see anything.

I'm not sure I understand why you see different results before and after
python-shell, but indeed I see that python.el incorrectly forces
font-lock-mode to be enabled in emacs-23.  I've just installed a patch
which should fix it.

> Visit a binary file, the nonprintable ascii is colored.

This is not controlled by font-lock.  IIUC this just unconditionally
receives the `escape-glyph' face, so you can only "turn it off" by
configuring this face.

> M-x compile

As mentioned above, this is the same issue as M-x grep.  I hope we can
fix it for Emacs-24 (by making compile.el use syntax-propertize-function
rather than font-lock), but for Emacs-23 the only solution I can offer
is to configure the relevant faces so they look the same as default.


        Stefan

Message #51 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: "K. Richard Pixley" <rich <at> noir.com>
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#7771: 23.1; can't turn off font-lock-mode globally
Date: Mon, 03 Jan 2011 00:34:35 -0500

> It's not a question of preference.  I literally cannot discern the
> characters on the screen when font lock is on.

Here are the known cases for this kind of problem:
- Your screen's colors are off-base.  Some possible cases are if you're
  running within an xterm whose color palette is more limited than usual
  or is somehow different from what Emacs expects.
- Emacs mis-identifies your background color and chooses the
  light-background set of colors rather than the dark-background set
  (or vice-versa).
  In this case, customizing frame-background-mode may help.
- Your vision is impaired.

I assumed you were in the third case, but maybe not.


        Stefan

Message #54 received at 7771 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 7771 <at> debbugs.gnu.org
Subject: Re: bug#7771: 23.1; can't turn off font-lock-mode globally
Date: Mon, 03 Jan 2011 00:57:32 -0500

Stefan Monnier wrote:

> python-shell, but indeed I see that python.el incorrectly forces
> font-lock-mode to be enabled in emacs-23.  I've just installed a patch
> which should fix it.

You would appear to have fixed bugs 3628 and 4303.
(Surely font-lock would not have been turned on unless the mode relied
on it for something, as the commentary suggests?)

Message #57 received at 7771 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>, 7771 <at> debbugs.gnu.org
Subject: Re: bug#7771: 23.1; can't turn off font-lock-mode globally
Date: Mon, 3 Jan 2011 01:00:54 -0500

Glenn Morris wrote (on Mon, 3 Jan 2011 at 00:57 -0500):

> You would appear to have fixed bugs 3628 and 4303.

I guess that's why you closed them; I apparently can't read...

Message #60 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "K. Richard Pixley" <rich <at> noir.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#7771: 23.1; can't turn off font-lock-mode globally
Date: Sun, 02 Jan 2011 22:52:29 -0800

On 20110102 21:34, Stefan Monnier wrote:
>> It's not a question of preference.  I literally cannot discern the
>> characters on the screen when font lock is on.
> Here are the known cases for this kind of problem:
> - Your screen's colors are off-base.  Some possible cases are if you're
>    running within an xterm whose color palette is more limited than usual
>    or is somehow different from what Emacs expects.
> - Emacs mis-identifies your background color and chooses the
>    light-background set of colors rather than the dark-background set
>    (or vice-versa).
>    In this case, customizing frame-background-mode may help.
> - Your vision is impaired.
>
> I assumed you were in the third case, but maybe not.
I'm probably in both of the last two and also a fourth.

I'm still setting emacs colors in Xdefaults having put some time 
investment into making that work some years ago.  It hadn't occurred to 
me that they might be interacting.

The fourth category is cognitive.  I am not neuro-typical.  Most color 
schemes just seem annoying to me.  Thunderbird's use of color works for 
me, eg, but M-x grep, M-x compile, and all of the font locked editing 
modes I've seen do not.  Color coding is difficult for me.  Numbers are 
much easier.

I'll try to find some time later this week to invest in coming up to 
speed with what's available now.  Maybe I can help.

--rich

Message #63 received at 7771 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Glenn Morris'" <rgm <at> gnu.org>, <7771 <at> debbugs.gnu.org>
Subject: RE: bug#7771: 23.1; can't turn off font-lock-mode globally
Date: Mon, 3 Jan 2011 00:13:03 -0800

> compile (and grep) require font-lock to work.

They did not used to require font locking.  This is a regression, a feature
loss, if users are deprived of the Emacs `grep' and `compile' commands if they
simply turn off font-locking.

The added benefit users get from font-lock should just be a plus, not a
requirement.  With font-lock turned off we should just not show any font-lock
highlighting, nothing more.

Font lock was finally turned on by default globally (a change I support
strongly).  But that should just be the _default_ behavior.  Font lock should
not be required in order to compile or grep.

As the person who first added regexp highlighting to the Emacs `grep' command
(my version), I know it is a definite plus.  But the implementation of the
`grep' and `compile' commands should not _require_ font locking for users to be
able to use the commands for their most important purpose.

Message #66 received at 7771 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>,
	"'K. Richard Pixley'" <rich <at> noir.com>
Cc: 7771 <at> debbugs.gnu.org
Subject: RE: bug#7771: 23.1; can't turn off font-lock-mode globally
Date: Mon, 3 Jan 2011 00:13:05 -0800

> OK, that one is a known problem: compile.el (used for M-x compile and
> M-x grep) uses font-lock internally, so it forces font-lock to
> be enabled.

Glad to hear it is seen as a bug. (It's a regression, since users lose a feature
they had previously: being able to compile or grep without font-locking.)

> I hope we can fix it for Emacs-24 (by making compile.el use 
> syntax-propertize-function rather than font-lock)

I too hope it gets fixed.

Message #69 received at 7771 <at> debbugs.gnu.org (full text, mbox):

From: Leo <sdl.web <at> gmail.com>
To: "K. Richard Pixley" <rich <at> noir.com>
Cc: 7771 <at> debbugs.gnu.org
Subject: Re: bug#7771: 23.1; can't turn off font-lock-mode globally
Date: Mon, 03 Jan 2011 08:48:40 +0000

On 2011-01-02 23:19 +0000, K. Richard Pixley wrote:
> Doesn't appear to be any different than (global-font-lock-mode 0).
>
> --rich

Did you see font locking off when starting Emacs -q? I can see this:
http://imgur.com/o6cFv.png

HTH,
Leo

Message #72 received at 7771 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lennart Borgman <lennart.borgman <at> gmail.com>
Cc: rgm <at> gnu.org, 7771 <at> debbugs.gnu.org
Subject: Re: bug#7771: 23.1; can't turn off font-lock-mode globally
Date: Mon, 03 Jan 2011 08:04:04 -0500

> From: Lennart Borgman <lennart.borgman <at> gmail.com>
> Date: Mon, 3 Jan 2011 04:21:38 +0100
> Cc: 7771 <at> debbugs.gnu.org
> 
> Richard, if you do not like the colors you can of course customize them.

Users who want to disable all colors should not be asked to customize
all the gazillion faces we have in Emacs.  Especially since some faces
are not even defined until their package is loaded.

Message #75 received at 7771 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: rgm <at> gnu.org, 7771 <at> debbugs.gnu.org
Subject: Re: bug#7771: 23.1; can't turn off font-lock-mode globally
Date: Mon, 03 Jan 2011 08:43:25 -0500

> From: "Drew Adams" <drew.adams <at> oracle.com>
> Date: Mon, 3 Jan 2011 00:13:03 -0800
> Cc: 
> 
> > compile (and grep) require font-lock to work.
> 
> They did not used to require font locking.  This is a regression, a feature
> loss, if users are deprived of the Emacs `grep' and `compile' commands if they
> simply turn off font-locking.

Users will not be deprived of anything, I think.  The problem is that
these features turn font-lock on in the compilation buffer, which is a
nuisance (for those who turned it off).

Message #78 received at 7771 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Eli Zaretskii'" <eliz <at> gnu.org>
Cc: rgm <at> gnu.org, 7771 <at> debbugs.gnu.org
Subject: RE: bug#7771: 23.1; can't turn off font-lock-mode globally
Date: Mon, 3 Jan 2011 08:00:34 -0800

> > > compile (and grep) require font-lock to work.
> > 
> > They did not used to require font locking.  This is a 
> > regression, a feature loss, if users are deprived of the
> > Emacs `grep' and `compile' commands if they
> > simply turn off font-locking.
> 
> Users will not be deprived of anything, I think.  The problem is that
> these features turn font-lock on in the compilation buffer, which is a
> nuisance (for those who turned it off).

Good.  But what was said was that "compile (and grep) require font-lock to
work".  That's what my comment responded to.

If that is not true, then users are not deprived of important functionality -
they need only turn font-lock back off after it gets turned on automatically in
the compilation buffer.  Annoying, but in that case we cannot say that grep and
compile will not work.

Message #81 received at 7771 <at> debbugs.gnu.org (full text, mbox):

From: Lennart Borgman <lennart.borgman <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: "K. Richard Pixley" <rich <at> noir.com>, 7771 <at> debbugs.gnu.org
Subject: Re: bug#7771: 23.1; can't turn off font-lock-mode globally
Date: Mon, 3 Jan 2011 17:42:48 +0100

On Mon, Jan 3, 2011 at 4:55 AM, Stefan Monnier <monnier <at> iro.umontreal.ca> wrote:
>
> As mentioned above, this is the same issue as M-x grep.  I hope we can
> fix it for Emacs-24 (by making compile.el use syntax-propertize-function
> rather than font-lock), but for Emacs-23 the only solution I can offer
> is to configure the relevant faces so they look the same as default.

Would it be possible to make a quick fix for needs like those we are
discussing here by just allowing font-lock to set a property 'noface
instead of face? Or perhaps allow the display engine to bypass the
'face property?

Message #84 received at 7771 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Lennart Borgman'" <lennart.borgman <at> gmail.com>,
	"'Stefan Monnier'" <monnier <at> iro.umontreal.ca>
Cc: "'K. Richard Pixley'" <rich <at> noir.com>, 7771 <at> debbugs.gnu.org
Subject: RE: bug#7771: 23.1; can't turn off font-lock-mode globally
Date: Mon, 3 Jan 2011 09:29:17 -0800

> Would it be possible to make a quick fix for needs like those we are
> discussing here by just allowing font-lock to set a property 'noface
> instead of face? Or perhaps allow the display engine to bypass the
> 'face property?

Eeeoooew! Ugh! cough, cough, hack, gulp, sigh

Message #87 received at 7771 <at> debbugs.gnu.org (full text, mbox):

From: Lennart Borgman <lennart.borgman <at> gmail.com>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: "K. Richard Pixley" <rich <at> noir.com>, 7771 <at> debbugs.gnu.org,
	Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#7771: 23.1; can't turn off font-lock-mode globally
Date: Mon, 3 Jan 2011 18:32:42 +0100

On Mon, Jan 3, 2011 at 6:29 PM, Drew Adams <drew.adams <at> oracle.com> wrote:
>> Would it be possible to make a quick fix for needs like those we are
>> discussing here by just allowing font-lock to set a property 'noface
>> instead of face? Or perhaps allow the display engine to bypass the
>> 'face property?
>
> Eeeoooew! Ugh! cough, cough, hack, gulp, sigh

What is happening to you? Anything I can do?

Message #90 received at 7771 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Lennart Borgman'" <lennart.borgman <at> gmail.com>
Cc: "'K. Richard Pixley'" <rich <at> noir.com>, 7771 <at> debbugs.gnu.org,
	'Stefan Monnier' <monnier <at> iro.umontreal.ca>
Subject: RE: bug#7771: 23.1; can't turn off font-lock-mode globally
Date: Mon, 3 Jan 2011 09:40:13 -0800

> > Eeeoooew! Ugh! cough, cough, hack, gulp, sigh
> 
> What is happening to you? Anything I can do?

LOL ;-)  Good one, Lennart.  I'll take a deep breath.

Message #93 received at 7771 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: rgm <at> gnu.org, 7771 <at> debbugs.gnu.org
Subject: Re: bug#7771: 23.1; can't turn off font-lock-mode globally
Date: Mon, 03 Jan 2011 20:01:48 +0200

> From: "Drew Adams" <drew.adams <at> oracle.com>
> Cc: <rgm <at> gnu.org>, <7771 <at> debbugs.gnu.org>
> Date: Mon, 3 Jan 2011 08:00:34 -0800
> 
> > Users will not be deprived of anything, I think.  The problem is that
> > these features turn font-lock on in the compilation buffer, which is a
> > nuisance (for those who turned it off).
> 
> Good.  But what was said was that "compile (and grep) require font-lock to
> work".  That's what my comment responded to.

I understand, but I think the original comment was slightly
inaccurate.  I think a more accurate statement would be
"compilation-mode needs font-lock to be turned on for its
functionality, so it turns it on unconditionally in the compilation
buffer."  Here's the code from compilation-setup:

  (set (make-local-variable 'font-lock-support-mode) nil)
  (set (make-local-variable 'font-lock-maximum-size) nil)
  (if minor
      (let ((fld font-lock-defaults))
	(font-lock-add-keywords nil (compilation-mode-font-lock-keywords))
	(if font-lock-mode
	    (if fld
		(font-lock-fontify-buffer)
	      (font-lock-change-mode)
	      (turn-on-font-lock))
	  (turn-on-font-lock)))
    (setq font-lock-defaults '(compilation-mode-font-lock-keywords t))
    ;; maybe defer font-lock till after derived mode is set up
    (run-mode-hooks 'compilation-turn-on-font-lock)))

and compilation-turn-on-font-lock is defined like this:

  (defconst compilation-turn-on-font-lock 'turn-on-font-lock)

Message #96 received at 7771 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Eli Zaretskii'" <eliz <at> gnu.org>
Cc: rgm <at> gnu.org, 7771 <at> debbugs.gnu.org
Subject: RE: bug#7771: 23.1; can't turn off font-lock-mode globally
Date: Mon, 3 Jan 2011 10:09:47 -0800

> I think a more accurate statement would be
> "compilation-mode needs font-lock to be turned on for its
> functionality, so it turns it on unconditionally in the compilation
> buffer."

Maybe that is more accurate, but the point of the thread is that
compilation-mode should _not_ "need font-lock to be turned on for its
functionality".

That was my point, anyway.  "Its functionality", at least its real raison
d'etre, does not include highlighting.  Highlighting is a nice-to-have (or not,
depending on one's preference).  It is not part of the core functionality.

But I think we all more or less agree that this should be fixed (as soon as it
can be).

Message #99 received at 7771 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: rgm <at> gnu.org, 7771 <at> debbugs.gnu.org
Subject: Re: bug#7771: 23.1; can't turn off font-lock-mode globally
Date: Mon, 03 Jan 2011 20:26:50 +0200

> From: "Drew Adams" <drew.adams <at> oracle.com>
> Cc: <rgm <at> gnu.org>, <7771 <at> debbugs.gnu.org>
> Date: Mon, 3 Jan 2011 10:09:47 -0800
> 
> > I think a more accurate statement would be
> > "compilation-mode needs font-lock to be turned on for its
> > functionality, so it turns it on unconditionally in the compilation
> > buffer."
> 
> Maybe that is more accurate, but the point of the thread is that
> compilation-mode should _not_ "need font-lock to be turned on for its
> functionality".

I agree.  I just wanted to point out that users who turn font-lock off
will not have M-x compile broken.

Message #102 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: "K. Richard Pixley" <rich <at> noir.com>
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#7771: 23.1; can't turn off font-lock-mode globally
Date: Mon, 03 Jan 2011 21:52:55 +0200

> From: "K. Richard Pixley" <rich <at> noir.com>
> Date: Mon, 03 Jan 2011 10:40:19 -0800
> 
> I believe that the fix needs to occur at a meta level to font lock.

What do you mean by "meta level to font lock"?

Message #105 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "K. Richard Pixley" <rich <at> noir.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#7771: 23.1; can't turn off font-lock-mode globally
Date: Mon, 03 Jan 2011 12:29:13 -0800

On 20110103 11:52, Eli Zaretskii wrote:
>> From: "K. Richard Pixley"<rich <at> noir.com>
>> Date: Mon, 03 Jan 2011 10:40:19 -0800
>>
>> I believe that the fix needs to occur at a meta level to font lock.
> What do you mean by "meta level to font lock"?
I mean that the mechanism for allowing or barring font lock apparently 
can't be part of the font lock subsystem.  It appears as though it will 
need to be outside the font-lock system in order to _gate_ the font lock 
system.

It appears as though people may be erroneously conflating font-lock 
modes with syntactic meaning of the underlying text and keying off 
font-lock values rather than the syntactic meanings.  This leads to the 
erroneous programmer impression that font-lock is a necessary 
prerequisite for their code, so they force it on.

Perhaps this is just an iteration of the "better lock, better lockpick, 
better lock, better lockpick" escalation cycle.  Perhaps there's another 
way to solve this problem without resorting to an escalation.  But as 
emacs is currently regressing, (can't use major modes that used to be 
available), it appears as though we are in dire need of a quick fix 
before emacs regresses to a point of complete inutility.

Either that, or we need to back off some recent changes and return to 
the code that worked.

--rich

Message #108 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: "K. Richard Pixley" <rich <at> noir.com>
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#7771: 23.1; can't turn off font-lock-mode globally
Date: Mon, 03 Jan 2011 22:39:30 +0200

> Date: Mon, 03 Jan 2011 12:29:13 -0800
> From: "K. Richard Pixley" <rich <at> noir.com>
> CC: bug-gnu-emacs <at> gnu.org
> 
> On 20110103 11:52, Eli Zaretskii wrote:
> >> From: "K. Richard Pixley"<rich <at> noir.com>
> >> Date: Mon, 03 Jan 2011 10:40:19 -0800
> >>
> >> I believe that the fix needs to occur at a meta level to font lock.
> > What do you mean by "meta level to font lock"?
> I mean that the mechanism for allowing or barring font lock apparently 
> can't be part of the font lock subsystem.  It appears as though it will 
> need to be outside the font-lock system in order to _gate_ the font lock 
> system.

That's what Lennart was proposing, AFAIU.

Btw, do you dislike _all_ colored text in Emacs, or only font-lock?
There are faces Emacs uses that are not related to font-lock at all,
like the "buttons" in *Help* buffers, the minibuffer prompts, the
special face for the part of file-name you type in the minibuffer that
will be ignored because it is before the "//", etc.  Then there are
colors not related to text, e.g. the fringes.  Do you want a feature
to turn all of those off, or just the font-lock faces?

> It appears as though people may be erroneously conflating font-lock 
> modes with syntactic meaning of the underlying text and keying off 
> font-lock values rather than the syntactic meanings.  This leads to the 
> erroneous programmer impression that font-lock is a necessary 
> prerequisite for their code, so they force it on.

You are entitled to your opinions, but to me syntax-sensitive colors
are an important feature because they show me my mistakes before they
hit the compiler.

Message #111 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Lennart Borgman <lennart.borgman <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: "K. Richard Pixley" <rich <at> noir.com>, bug-gnu-emacs <at> gnu.org
Subject: Re: bug#7771: 23.1; can't turn off font-lock-mode globally
Date: Mon, 3 Jan 2011 22:02:34 +0100

On Mon, Jan 3, 2011 at 9:39 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> Date: Mon, 03 Jan 2011 12:29:13 -0800
>> From: "K. Richard Pixley" <rich <at> noir.com>
>> CC: bug-gnu-emacs <at> gnu.org
>>
>> On 20110103 11:52, Eli Zaretskii wrote:
>> >> From: "K. Richard Pixley"<rich <at> noir.com>
>> >> Date: Mon, 03 Jan 2011 10:40:19 -0800
>> >>
>> >> I believe that the fix needs to occur at a meta level to font lock.
>> > What do you mean by "meta level to font lock"?
>> I mean that the mechanism for allowing or barring font lock apparently
>> can't be part of the font lock subsystem.  It appears as though it will
>> need to be outside the font-lock system in order to _gate_ the font lock
>> system.
>
> That's what Lennart was proposing, AFAIU.
>
> Btw, do you dislike _all_ colored text in Emacs, or only font-lock?
> There are faces Emacs uses that are not related to font-lock at all,
> like the "buttons" in *Help* buffers, the minibuffer prompts, the
> special face for the part of file-name you type in the minibuffer that
> will be ignored because it is before the "//", etc.  Then there are
> colors not related to text, e.g. the fringes.  Do you want a feature
> to turn all of those off, or just the font-lock faces?

Regarding my proposal: Eli, your question is good, just adding a
point. I would expect it to be only face colors that are the problem,
but I am not sure. Richard?

Message #114 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "K. Richard Pixley" <rich <at> noir.com>
To: Lennart Borgman <lennart.borgman <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, bug-gnu-emacs <at> gnu.org
Subject: Re: bug#7771: 23.1; can't turn off font-lock-mode globally
Date: Mon, 03 Jan 2011 13:30:48 -0800

On 20110103 13:02, Lennart Borgman wrote:
> On Mon, Jan 3, 2011 at 9:39 PM, Eli Zaretskii<eliz <at> gnu.org>  wrote:
>> Btw, do you dislike _all_ colored text in Emacs, or only font-lock?
>> There are faces Emacs uses that are not related to font-lock at all,
>> like the "buttons" in *Help* buffers, the minibuffer prompts, the
>> special face for the part of file-name you type in the minibuffer that
>> will be ignored because it is before the "//", etc.  Then there are
>> colors not related to text, e.g. the fringes.  Do you want a feature
>> to turn all of those off, or just the font-lock faces?
>> Regarding my proposal: Eli, your question is good, just adding a
>> point. I would expect it to be only face colors that are the problem,
>> but I am not sure. Richard?
For me, it's gratuitous use of color, (the effect is not unlike a mix of 
sTudLy CAps with
i VIs     Ch   cTe  ), and non-contrasting colors, (of which there are 
more for some people than others).

The buttons I've seen in the last two days had no color difference from 
the rest of the text in the popup.

The minibuffer prompts, as I recall, appear to be dimmed, not colored, 
(although that may just be clever use of color), and largely remove bits 
of no interest anyway.  (Didn't the minibuffer used to clear on "//" 
rather than even showing the previous text?).

I have no complaint or problem with dimmed or bolded.  Dimmed certainly 
could become illegible if it were sufficiently dim, but it seems to be 
fine in most cases.  Unlike, say, dim yellow text on off white 
background which is essentially invisible.  Or red on green background 
or yellow on blue, (or vice verse), which are completely invisible.

Most programmers aren't color experts.  They just slap up what seem like 
contrasting colors to them without much thought to subjective 
experience, (color blindness, cognitive variance, environmental factors 
like X11 themeing), color set themeing, look-and-feel coordination, 
pleasing presentation, etc.

Thunderbird uses color and I find their use of color constructive.

It's low/no contrast color and "bad" use of color to which I object, 
(and 95% of color uses are "bad", ime).

I want the "bad" color to go away.  And that seems to be primarily 
font-lock uses.

--rich
ps, for those who don't get it yet, my first sentence above was intended 
to mimic low/no contrast "studly caps with invisible characters".

Message #117 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Lennart Borgman <lennart.borgman <at> gmail.com>
To: "K. Richard Pixley" <rich <at> noir.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, bug-gnu-emacs <at> gnu.org
Subject: Re: bug#7771: 23.1; can't turn off font-lock-mode globally
Date: Mon, 3 Jan 2011 23:04:36 +0100

On Mon, Jan 3, 2011 at 10:30 PM, K. Richard Pixley <rich <at> noir.com> wrote:
> On 20110103 13:02, Lennart Borgman wrote:
>>
> I have no complaint or problem with dimmed or bolded.  Dimmed certainly
> could become illegible if it were sufficiently dim, but it seems to be fine
> in most cases.  Unlike, say, dim yellow text on off white background which
> is essentially invisible.  Or red on green background or yellow on blue, (or
> vice verse), which are completely invisible.
>
> Most programmers aren't color experts.  They just slap up what seem like
> contrasting colors to them without much thought to subjective experience,
> (color blindness, cognitive variance, environmental factors like X11
> themeing), color set themeing, look-and-feel coordination, pleasing
> presentation, etc.
>
> Thunderbird uses color and I find their use of color constructive.
>
> It's low/no contrast color and "bad" use of color to which I object, (and
> 95% of color uses are "bad", ime).
>
> I want the "bad" color to go away.  And that seems to be primarily font-lock
> uses.

Then perhaps the best solution would rather be a color theme adjusted
to your needs? I mean in case that is possible to figure out on a more
general level. Since you say that thunderbird seems to have done that
it looks possible to me.

Message #120 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "K. Richard Pixley" <rich <at> noir.com>
To: Lennart Borgman <lennart.borgman <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, bug-gnu-emacs <at> gnu.org
Subject: Re: bug#7771: 23.1; can't turn off font-lock-mode globally
Date: Mon, 03 Jan 2011 14:14:22 -0800

On 20110103 14:04, Lennart Borgman wrote:
> On Mon, Jan 3, 2011 at 10:30 PM, K. Richard Pixley<rich <at> noir.com>  wrote:
>> On 20110103 13:02, Lennart Borgman wrote:
>> I have no complaint or problem with dimmed or bolded.  Dimmed certainly
>> could become illegible if it were sufficiently dim, but it seems to be fine
>> in most cases.  Unlike, say, dim yellow text on off white background which
>> is essentially invisible.  Or red on green background or yellow on blue, (or
>> vice verse), which are completely invisible.
>>
>> Most programmers aren't color experts.  They just slap up what seem like
>> contrasting colors to them without much thought to subjective experience,
>> (color blindness, cognitive variance, environmental factors like X11
>> themeing), color set themeing, look-and-feel coordination, pleasing
>> presentation, etc.
>>
>> Thunderbird uses color and I find their use of color constructive.
>>
>> It's low/no contrast color and "bad" use of color to which I object, (and
>> 95% of color uses are "bad", ime).
>>
>> I want the "bad" color to go away.  And that seems to be primarily font-lock
>> uses.
> Then perhaps the best solution would rather be a color theme adjusted
> to your needs? I mean in case that is possible to figure out on a more
> general level. Since you say that thunderbird seems to have done that
> it looks possible to me.
Part of my point here is that creating a color theme that is 
sufficiently general is beyond the scope of most programmers.  Making 
"bad" color the default is a poor choice if it can be turned off but 
it's a horrendous choice if it cannot.

Certainly, a professionally color themed emacs by a color expert might 
be a better choice.  However, most of us are programmers, not color 
experts.  Turning the functionality off should be within our scope while 
creating expert color themes probably isn't.

I mean no offense to anyone in particular, but even if we held a contest 
for best color theme, selected the top dozen or so to go into emacs as 
available alternatives, there would still be people who didn't like any 
of the available options or who simply don't like color coding.  For 
them, the best UI would be an option to "turn color coding off" rather 
than to create a set of monochrome color themes.

--rich

Message #123 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: "K. Richard Pixley" <rich <at> noir.com>
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#7771: 23.1; can't turn off font-lock-mode globally
Date: Tue, 04 Jan 2011 06:05:23 +0200

> From: "K. Richard Pixley" <rich <at> noir.com>
> Date: Mon, 03 Jan 2011 14:23:14 -0800
> 
> What I'm doing manually is cursing a bit, then switching buffers and 
> manually typing (global-font-lock-mode 0) to make these popups visible. 
>   I wonder if we couldn't automate that process?  (Excepting, perhaps 
> the cursing.)
> 
> Would it make sense to push the current value of global-font-lock-mode, 
> run the rest of what these guys do, then restore the value of 
> global-font-lock-mode afterwards?  That is, wrap them in a sort of 
> context manager?

What does global-font-lock-mode have to do with this?  Compilation
mode only turns on font-lock in the current buffer, normally the
compilation buffer.  So just turning it off in that buffer (with
"M-x font-lock-mode RET")  should be enough.  Or am I missing
something?

Message #126 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "K. Richard Pixley" <rich <at> noir.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#7771: 23.1; can't turn off font-lock-mode globally
Date: Mon, 03 Jan 2011 20:21:19 -0800

On 20110103 20:05, Eli Zaretskii wrote:
>> From: "K. Richard Pixley"<rich <at> noir.com>
>> Date: Mon, 03 Jan 2011 14:23:14 -0800
>>
>> What I'm doing manually is cursing a bit, then switching buffers and
>> manually typing (global-font-lock-mode 0) to make these popups visible.
>>    I wonder if we couldn't automate that process?  (Excepting, perhaps
>> the cursing.)
>>
>> Would it make sense to push the current value of global-font-lock-mode,
>> run the rest of what these guys do, then restore the value of
>> global-font-lock-mode afterwards?  That is, wrap them in a sort of
>> context manager?
> What does global-font-lock-mode have to do with this?  Compilation
> mode only turns on font-lock in the current buffer, normally the
> compilation buffer.  So just turning it off in that buffer (with
> "M-x font-lock-mode RET")  should be enough.  Or am I missing
> something?
That's probably sufficient.  I'm using being emphatic while I'm cursing 
and somehow global seems more emphatic than local.

--rich

Message #131 received at 7771-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: 801-done <at> debbugs.gnu.org, 7771-done <at> debbugs.gnu.org
Subject: compile.el and font-lock
Date: Fri, 28 Jan 2011 17:19:56 -0500

I've just pushed a change which makes M-x compile and M-x grep work
without forcing font-lock to be enabled.  They also make the
error-parsing lazier, so it may be faster in some cases (tho probably
slower in others as well: speed was not the main focus of my coding).


        Stefan

Previous Next

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