bug#7771: 23.1; can't turn off font-lock-mode globally

bug#7771: 23.1; can't turn off font-lock-mode globally

[K. Richard Pixley]

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

bug#7771: 23.1; can't turn off font-lock-mode globally

[Leo]

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

bug#7771: 23.1; can't turn off font-lock-mode globally

[K. Richard Pixley]

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

bug#7771: 23.1; can't turn off font-lock-mode globally

[Leo]

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

bug#7771: 23.1; can't turn off font-lock-mode globally

[Stefan Monnier]

> (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

bug#7771: 23.1; can't turn off font-lock-mode globally

[K. Richard Pixley]

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

bug#7771: 23.1; can't turn off font-lock-mode globally

[Stefan Monnier]

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

bug#7771: 23.1; can't turn off font-lock-mode globally

[Glenn Morris]

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?)

bug#7771: 23.1; can't turn off font-lock-mode globally

[Glenn Morris]

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...

Re: bug#7771: 23.1; can't turn off font-lock-mode globally

[K. Richard Pixley]

On 20110102 22:00, Glenn Morris wrote:
>
> 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...

Try (global-font-lock-mode 0).

Er...

--rich :).

bug#7771: 23.1; can't turn off font-lock-mode globally

[Drew Adams]

> 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.

bug#7771: 23.1; can't turn off font-lock-mode globally

[Lennart Borgman]

On Mon, Jan 3, 2011 at 4:55 AM, Stefan Monnier <monnier@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?

bug#7771: 23.1; can't turn off font-lock-mode globally

[Drew Adams]

> 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

bug#7771: 23.1; can't turn off font-lock-mode globally

[Lennart Borgman]

On Mon, Jan 3, 2011 at 6:29 PM, Drew Adams <drew.adams@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?

bug#7771: 23.1; can't turn off font-lock-mode globally

[Drew Adams]

> > 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.

Re: bug#7771: 23.1; can't turn off font-lock-mode globally

[K. Richard Pixley]

On 20110103 08:42, Lennart Borgman wrote:
> On Mon, Jan 3, 2011 at 4:55 AM, Stefan Monnier<monnier@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?

I believe that the fix needs to occur at a meta level to font lock.  If 
modes are changing a user preference randomly, that's not good.  The 
user preference needs to take precedence.  It sounds as though it needs 
to be possible to prevent font locking from being turned on.

--rich

bug#7771: 23.1; can't turn off font-lock-mode globally

[Eli Zaretskii]

> From: "K. Richard Pixley" <rich@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"?

bug#7771: 23.1; can't turn off font-lock-mode globally

[K. Richard Pixley]

On 20110103 11:52, Eli Zaretskii wrote:
>> From: "K. Richard Pixley"<rich@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

bug#7771: 23.1; can't turn off font-lock-mode globally

[Eli Zaretskii]

> Date: Mon, 03 Jan 2011 12:29:13 -0800
> From: "K. Richard Pixley" <rich@noir.com>
> CC: bug-gnu-emacs@gnu.org
> 
> On 20110103 11:52, Eli Zaretskii wrote:
> >> From: "K. Richard Pixley"<rich@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.

bug#7771: 23.1; can't turn off font-lock-mode globally

[Lennart Borgman]

On Mon, Jan 3, 2011 at 9:39 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Mon, 03 Jan 2011 12:29:13 -0800
>> From: "K. Richard Pixley" <rich@noir.com>
>> CC: bug-gnu-emacs@gnu.org
>>
>> On 20110103 11:52, Eli Zaretskii wrote:
>> >> From: "K. Richard Pixley"<rich@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?

bug#7771: 23.1; can't turn off font-lock-mode globally

[K. Richard Pixley]

On 20110103 13:02, Lennart Borgman wrote:
> On Mon, Jan 3, 2011 at 9:39 PM, Eli Zaretskii<eliz@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".

bug#7771: 23.1; can't turn off font-lock-mode globally

[Lennart Borgman]

On Mon, Jan 3, 2011 at 10:30 PM, K. Richard Pixley <rich@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.

bug#7771: 23.1; can't turn off font-lock-mode globally

[K. Richard Pixley]

On 20110103 14:04, Lennart Borgman wrote:
> On Mon, Jan 3, 2011 at 10:30 PM, K. Richard Pixley<rich@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

Re: bug#7771: 23.1; can't turn off font-lock-mode globally

[K. Richard Pixley]

On 20110103 12:39, Eli Zaretskii wrote:
>> 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.

I'm not arguing about whether syntax sensitive colors are an important 
feature.  I agree that it makes sense for emacs to make this feature 
available.

I have similar functionality from autoindent, blink paren closing, etc 
so I do understand that when these work, they provide earlier notice of 
problems.

My argument is that syntax sensitivity should be available independently 
of color presentation.  That is, I should have blink matching parens, 
autoindent, etc, even if I have colors turned off.

--rich

Re: bug#7771: 23.1; can't turn off font-lock-mode globally

[K. Richard Pixley]

On 20110102 19:55, Stefan Monnier wrote:
>> 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.

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?

The end result for me would be a legible buffer and for everyone else 
would be essentially the same thing they have now.

--rich

bug#7771: 23.1; can't turn off font-lock-mode globally

[Eli Zaretskii]

> From: "K. Richard Pixley" <rich@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?

bug#7771: 23.1; can't turn off font-lock-mode globally

[K. Richard Pixley]

On 20110103 20:05, Eli Zaretskii wrote:
>> From: "K. Richard Pixley"<rich@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

bug#7771: 23.1; can't turn off font-lock-mode globally

[K. Richard Pixley]

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

bug#7771: 23.1; can't turn off font-lock-mode globally

[Glenn Morris]

"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.

bug#7771: 23.1; can't turn off font-lock-mode globally

[Lennart Borgman]

On Mon, Jan 3, 2011 at 2:55 AM, Glenn Morris <rgm@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.

bug#7771: 23.1; can't turn off font-lock-mode globally

[Eli Zaretskii]

> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Mon, 3 Jan 2011 04:21:38 +0100
> Cc: 7771@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.

Re: bug#7771: 23.1; can't turn off font-lock-mode globally

[K. Richard Pixley]

On 20110102 19:21, Lennart Borgman wrote:
> On Mon, Jan 3, 2011 at 2:55 AM, Glenn Morris<rgm@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.

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

Some day, I may well try to set up colors that work.  But that's a very 
slow process for me.  It took me several days to do it via X defaults 
the last time I tried.  For now, I just want my screen visible again. 
And font-lock mode appears to be the culprit.

If color customization were easy, wouldn't there be a functional 
(global-font-lock-mode 0)?

--rich

bug#7771: 23.1; can't turn off font-lock-mode globally

[Stefan Monnier]

> 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

bug#7771: 23.1; can't turn off font-lock-mode globally

[K. Richard Pixley]

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

bug#7771: 23.1; can't turn off font-lock-mode globally

[Drew Adams]

> 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.

bug#7771: 23.1; can't turn off font-lock-mode globally

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@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).

bug#7771: 23.1; can't turn off font-lock-mode globally

[Drew Adams]

> > > 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.

bug#7771: 23.1; can't turn off font-lock-mode globally

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <rgm@gnu.org>, <7771@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)

bug#7771: 23.1; can't turn off font-lock-mode globally

[Drew Adams]

> 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).

bug#7771: 23.1; can't turn off font-lock-mode globally

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <rgm@gnu.org>, <7771@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.

Re: bug#7771: 23.1; can't turn off font-lock-mode globally

[K. Richard Pixley]

On 20110103 05:43, Eli Zaretskii wrote:
>> From: "Drew Adams"<drew.adams@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).

I think this is a question of user level.

I'm a pretty advanced and long time emacs users.  But I know nothing of 
faces or font lock mode.  I only know that when these buffers pop up 
they are illegible now where previously I relied on them quite heavily. 
  M-x compile and M-x next-error make emacs historically one of the 
first IDE's and still one of the most powerful.

There's no easy path to figuring out why or how to fix them.  In effect, 
the modes are unavailable.  I mean, they're available, but they are 
illegible.

--rich

Re: bug#7771: 23.1; can't turn off font-lock-mode globally

[K. Richard Pixley]

On 20110103 00:13, Drew Adams wrote:
>> 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.

I concur.  This is a sad regression.

> 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.

As is, it's not a plus.  It simply makes those commands difficult to 
use.  You have to switch to the buffer and manually turn font locking 
off in them each time you create a pop up in order to view the pop up's 
contents.

(I haven't tried to set up a mode-local hook to do it.)

> 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.

I think it could be a reasonable default if it were visible in all 
cases.  Since it's clearly not, it is, in my opinion, premature to turn 
on by default.

New users and people who are ignorant of the font lock system should not 
be presented with illegible screens nor be forced to learn the details 
of this system simply in order to use emacs.

IMO, that's intolerable and extremely embarrassing.  I can't very well 
advocate for emacs use when this is such a common occurrence.

> 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.

Again, I strongly concur.

As a model, assume for a moment that "font-lock" meant "white characters 
on a white background".

--rich

Re: bug#7771: 23.1; can't turn off font-lock-mode globally

[K. Richard Pixley]

On 20110102 17:55, Glenn Morris 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.

Yikes.  That's horrible!

I've been a stalwart emacs user since before GNU or the FSF existed. 
But this kind of regression is nasty.

Thanks for the info.

--rich

bug#7771: 23.1; can't turn off font-lock-mode globally

[K. Richard Pixley]

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

bug#7771: 23.1; can't turn off font-lock-mode globally

[K. Richard Pixley]

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

bug#7771: 23.1; can't turn off font-lock-mode globally

[Glenn Morris]

"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

bug#7771: 23.1; can't turn off font-lock-mode globally

[Glenn Morris]

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.