* bug#7771: 23.1; can't turn off font-lock-mode globally
@ 2011-01-02 19:17 K. Richard Pixley
2011-01-02 22:56 ` Leo
2011-01-02 23:49 ` Stefan Monnier
0 siblings, 2 replies; 47+ messages in thread
From: K. Richard Pixley @ 2011-01-02 19:17 UTC (permalink / raw)
To: 7771
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
^ permalink raw reply [flat|nested] 47+ messages in thread
* bug#7771: 23.1; can't turn off font-lock-mode globally
2011-01-02 19:17 bug#7771: 23.1; can't turn off font-lock-mode globally K. Richard Pixley
@ 2011-01-02 22:56 ` Leo
2011-01-02 23:19 ` K. Richard Pixley
2011-01-02 23:49 ` Stefan Monnier
1 sibling, 1 reply; 47+ messages in thread
From: Leo @ 2011-01-02 22:56 UTC (permalink / raw)
To: K. Richard Pixley; +Cc: 7771
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
^ permalink raw reply [flat|nested] 47+ messages in thread
* bug#7771: 23.1; can't turn off font-lock-mode globally
2011-01-02 22:56 ` Leo
@ 2011-01-02 23:19 ` K. Richard Pixley
2011-01-03 8:48 ` Leo
0 siblings, 1 reply; 47+ messages in thread
From: K. Richard Pixley @ 2011-01-02 23:19 UTC (permalink / raw)
To: Leo; +Cc: 7771
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
^ permalink raw reply [flat|nested] 47+ messages in thread
* bug#7771: 23.1; can't turn off font-lock-mode globally
2011-01-02 19:17 bug#7771: 23.1; can't turn off font-lock-mode globally K. Richard Pixley
2011-01-02 22:56 ` Leo
@ 2011-01-02 23:49 ` Stefan Monnier
2011-01-03 0:27 ` K. Richard Pixley
` (3 more replies)
1 sibling, 4 replies; 47+ messages in thread
From: Stefan Monnier @ 2011-01-02 23:49 UTC (permalink / raw)
To: K. Richard Pixley; +Cc: 7771
> (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
^ permalink raw reply [flat|nested] 47+ messages in thread
* bug#7771: 23.1; can't turn off font-lock-mode globally
2011-01-02 23:49 ` Stefan Monnier
@ 2011-01-03 0:27 ` K. Richard Pixley
2011-01-03 3:55 ` Stefan Monnier
[not found] ` <mailman.1.1294028628.27854.bug-gnu-emacs@gnu.org>
2011-01-03 0:29 ` K. Richard Pixley
` (2 subsequent siblings)
3 siblings, 2 replies; 47+ messages in thread
From: K. Richard Pixley @ 2011-01-03 0:27 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 7771
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
^ permalink raw reply [flat|nested] 47+ messages in thread
* bug#7771: 23.1; can't turn off font-lock-mode globally
2011-01-02 23:49 ` Stefan Monnier
2011-01-03 0:27 ` K. Richard Pixley
@ 2011-01-03 0:29 ` K. Richard Pixley
2011-01-03 1:55 ` Glenn Morris
[not found] ` <mailman.22.1294021456.15403.bug-gnu-emacs@gnu.org>
2011-01-03 0:31 ` K. Richard Pixley
2011-01-03 1:20 ` K. Richard Pixley
3 siblings, 2 replies; 47+ messages in thread
From: K. Richard Pixley @ 2011-01-03 0:29 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 7771
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
^ permalink raw reply [flat|nested] 47+ messages in thread
* bug#7771: 23.1; can't turn off font-lock-mode globally
2011-01-02 23:49 ` Stefan Monnier
2011-01-03 0:27 ` K. Richard Pixley
2011-01-03 0:29 ` K. Richard Pixley
@ 2011-01-03 0:31 ` K. Richard Pixley
2011-01-03 1:20 ` K. Richard Pixley
3 siblings, 0 replies; 47+ messages in thread
From: K. Richard Pixley @ 2011-01-03 0:31 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 7771
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
^ permalink raw reply [flat|nested] 47+ messages in thread
* bug#7771: 23.1; can't turn off font-lock-mode globally
2011-01-02 23:49 ` Stefan Monnier
` (2 preceding siblings ...)
2011-01-03 0:31 ` K. Richard Pixley
@ 2011-01-03 1:20 ` K. Richard Pixley
2011-01-03 1:54 ` Glenn Morris
3 siblings, 1 reply; 47+ messages in thread
From: K. Richard Pixley @ 2011-01-03 1:20 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 7771
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
^ permalink raw reply [flat|nested] 47+ messages in thread
* bug#7771: 23.1; can't turn off font-lock-mode globally
2011-01-03 1:20 ` K. Richard Pixley
@ 2011-01-03 1:54 ` Glenn Morris
2011-01-03 2:08 ` Glenn Morris
0 siblings, 1 reply; 47+ messages in thread
From: Glenn Morris @ 2011-01-03 1:54 UTC (permalink / raw)
To: 7771
"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
^ permalink raw reply [flat|nested] 47+ messages in thread
* bug#7771: 23.1; can't turn off font-lock-mode globally
2011-01-03 0:29 ` K. Richard Pixley
@ 2011-01-03 1:55 ` Glenn Morris
2011-01-03 3:21 ` Lennart Borgman
` (3 more replies)
[not found] ` <mailman.22.1294021456.15403.bug-gnu-emacs@gnu.org>
1 sibling, 4 replies; 47+ messages in thread
From: Glenn Morris @ 2011-01-03 1:55 UTC (permalink / raw)
To: 7771
"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.
^ permalink raw reply [flat|nested] 47+ messages in thread
* bug#7771: 23.1; can't turn off font-lock-mode globally
2011-01-03 1:54 ` Glenn Morris
@ 2011-01-03 2:08 ` Glenn Morris
0 siblings, 0 replies; 47+ messages in thread
From: Glenn Morris @ 2011-01-03 2:08 UTC (permalink / raw)
To: 7771
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.
^ permalink raw reply [flat|nested] 47+ messages in thread
* bug#7771: 23.1; can't turn off font-lock-mode globally
2011-01-03 1:55 ` Glenn Morris
@ 2011-01-03 3:21 ` Lennart Borgman
2011-01-03 13:04 ` Eli Zaretskii
[not found] ` <mailman.30.1294025024.15403.bug-gnu-emacs@gnu.org>
` (2 subsequent siblings)
3 siblings, 1 reply; 47+ messages in thread
From: Lennart Borgman @ 2011-01-03 3:21 UTC (permalink / raw)
To: Glenn Morris; +Cc: 7771
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.
^ permalink raw reply [flat|nested] 47+ messages in thread
* bug#7771: 23.1; can't turn off font-lock-mode globally
2011-01-03 0:27 ` K. Richard Pixley
@ 2011-01-03 3:55 ` Stefan Monnier
2011-01-03 5:57 ` Glenn Morris
` (3 more replies)
[not found] ` <mailman.1.1294028628.27854.bug-gnu-emacs@gnu.org>
1 sibling, 4 replies; 47+ messages in thread
From: Stefan Monnier @ 2011-01-03 3:55 UTC (permalink / raw)
To: K. Richard Pixley; +Cc: 7771
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
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: bug#7771: 23.1; can't turn off font-lock-mode globally
[not found] ` <mailman.30.1294025024.15403.bug-gnu-emacs@gnu.org>
@ 2011-01-03 4:10 ` K. Richard Pixley
2011-01-03 5:34 ` Stefan Monnier
0 siblings, 1 reply; 47+ messages in thread
From: K. Richard Pixley @ 2011-01-03 4:10 UTC (permalink / raw)
To: bug-gnu-emacs
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
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: bug#7771: 23.1; can't turn off font-lock-mode globally
[not found] ` <mailman.22.1294021456.15403.bug-gnu-emacs@gnu.org>
@ 2011-01-03 4:14 ` K. Richard Pixley
0 siblings, 0 replies; 47+ messages in thread
From: K. Richard Pixley @ 2011-01-03 4:14 UTC (permalink / raw)
To: bug-gnu-emacs
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
^ permalink raw reply [flat|nested] 47+ messages in thread
* bug#7771: 23.1; can't turn off font-lock-mode globally
2011-01-03 4:10 ` K. Richard Pixley
@ 2011-01-03 5:34 ` Stefan Monnier
2011-01-03 6:52 ` K. Richard Pixley
0 siblings, 1 reply; 47+ messages in thread
From: Stefan Monnier @ 2011-01-03 5:34 UTC (permalink / raw)
To: K. Richard Pixley; +Cc: bug-gnu-emacs
> 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
^ permalink raw reply [flat|nested] 47+ messages in thread
* bug#7771: 23.1; can't turn off font-lock-mode globally
2011-01-03 3:55 ` Stefan Monnier
@ 2011-01-03 5:57 ` Glenn Morris
2011-01-03 6:00 ` Glenn Morris
[not found] ` <mailman.4.1294035825.27854.bug-gnu-emacs@gnu.org>
2011-01-03 8:13 ` Drew Adams
` (2 subsequent siblings)
3 siblings, 2 replies; 47+ messages in thread
From: Glenn Morris @ 2011-01-03 5:57 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 7771
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?)
^ permalink raw reply [flat|nested] 47+ messages in thread
* bug#7771: 23.1; can't turn off font-lock-mode globally
2011-01-03 5:57 ` Glenn Morris
@ 2011-01-03 6:00 ` Glenn Morris
[not found] ` <mailman.4.1294035825.27854.bug-gnu-emacs@gnu.org>
1 sibling, 0 replies; 47+ messages in thread
From: Glenn Morris @ 2011-01-03 6:00 UTC (permalink / raw)
To: Stefan Monnier, 7771
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...
^ permalink raw reply [flat|nested] 47+ messages in thread
* bug#7771: 23.1; can't turn off font-lock-mode globally
2011-01-03 5:34 ` Stefan Monnier
@ 2011-01-03 6:52 ` K. Richard Pixley
0 siblings, 0 replies; 47+ messages in thread
From: K. Richard Pixley @ 2011-01-03 6:52 UTC (permalink / raw)
To: Stefan Monnier; +Cc: bug-gnu-emacs
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
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: bug#7771: 23.1; can't turn off font-lock-mode globally
[not found] ` <mailman.4.1294035825.27854.bug-gnu-emacs@gnu.org>
@ 2011-01-03 6:56 ` K. Richard Pixley
0 siblings, 0 replies; 47+ messages in thread
From: K. Richard Pixley @ 2011-01-03 6:56 UTC (permalink / raw)
To: bug-gnu-emacs
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 :).
^ permalink raw reply [flat|nested] 47+ messages in thread
* bug#7771: 23.1; can't turn off font-lock-mode globally
2011-01-03 1:55 ` Glenn Morris
2011-01-03 3:21 ` Lennart Borgman
[not found] ` <mailman.30.1294025024.15403.bug-gnu-emacs@gnu.org>
@ 2011-01-03 8:13 ` Drew Adams
2011-01-03 13:43 ` Eli Zaretskii
[not found] ` <mailman.1.1294062865.25287.bug-gnu-emacs@gnu.org>
[not found] ` <mailman.10.1294043026.27854.bug-gnu-emacs@gnu.org>
3 siblings, 2 replies; 47+ messages in thread
From: Drew Adams @ 2011-01-03 8:13 UTC (permalink / raw)
To: 'Glenn Morris', 7771
> 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.
^ permalink raw reply [flat|nested] 47+ messages in thread
* bug#7771: 23.1; can't turn off font-lock-mode globally
2011-01-03 3:55 ` Stefan Monnier
2011-01-03 5:57 ` Glenn Morris
@ 2011-01-03 8:13 ` Drew Adams
2011-01-03 16:42 ` Lennart Borgman
[not found] ` <mailman.1.1294073635.27149.bug-gnu-emacs@gnu.org>
3 siblings, 0 replies; 47+ messages in thread
From: Drew Adams @ 2011-01-03 8:13 UTC (permalink / raw)
To: 'Stefan Monnier', 'K. Richard Pixley'; +Cc: 7771
> 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.
^ permalink raw reply [flat|nested] 47+ messages in thread
* bug#7771: 23.1; can't turn off font-lock-mode globally
2011-01-02 23:19 ` K. Richard Pixley
@ 2011-01-03 8:48 ` Leo
0 siblings, 0 replies; 47+ messages in thread
From: Leo @ 2011-01-03 8:48 UTC (permalink / raw)
To: K. Richard Pixley; +Cc: 7771
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
^ permalink raw reply [flat|nested] 47+ messages in thread
* bug#7771: 23.1; can't turn off font-lock-mode globally
2011-01-03 3:21 ` Lennart Borgman
@ 2011-01-03 13:04 ` Eli Zaretskii
0 siblings, 0 replies; 47+ messages in thread
From: Eli Zaretskii @ 2011-01-03 13:04 UTC (permalink / raw)
To: Lennart Borgman; +Cc: 7771
> 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.
^ permalink raw reply [flat|nested] 47+ messages in thread
* bug#7771: 23.1; can't turn off font-lock-mode globally
2011-01-03 8:13 ` Drew Adams
@ 2011-01-03 13:43 ` Eli Zaretskii
2011-01-03 16:00 ` Drew Adams
[not found] ` <mailman.1.1294062865.25287.bug-gnu-emacs@gnu.org>
1 sibling, 1 reply; 47+ messages in thread
From: Eli Zaretskii @ 2011-01-03 13:43 UTC (permalink / raw)
To: Drew Adams; +Cc: 7771
> 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).
^ permalink raw reply [flat|nested] 47+ messages in thread
* bug#7771: 23.1; can't turn off font-lock-mode globally
2011-01-03 13:43 ` Eli Zaretskii
@ 2011-01-03 16:00 ` Drew Adams
2011-01-03 18:01 ` Eli Zaretskii
0 siblings, 1 reply; 47+ messages in thread
From: Drew Adams @ 2011-01-03 16:00 UTC (permalink / raw)
To: 'Eli Zaretskii'; +Cc: 7771
> > > 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.
^ permalink raw reply [flat|nested] 47+ messages in thread
* bug#7771: 23.1; can't turn off font-lock-mode globally
2011-01-03 3:55 ` Stefan Monnier
2011-01-03 5:57 ` Glenn Morris
2011-01-03 8:13 ` Drew Adams
@ 2011-01-03 16:42 ` Lennart Borgman
2011-01-03 17:29 ` Drew Adams
[not found] ` <mailman.1.1294073635.27149.bug-gnu-emacs@gnu.org>
3 siblings, 1 reply; 47+ messages in thread
From: Lennart Borgman @ 2011-01-03 16:42 UTC (permalink / raw)
To: Stefan Monnier; +Cc: K. Richard Pixley, 7771
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?
^ permalink raw reply [flat|nested] 47+ messages in thread
* bug#7771: 23.1; can't turn off font-lock-mode globally
2011-01-03 16:42 ` Lennart Borgman
@ 2011-01-03 17:29 ` Drew Adams
2011-01-03 17:32 ` Lennart Borgman
0 siblings, 1 reply; 47+ messages in thread
From: Drew Adams @ 2011-01-03 17:29 UTC (permalink / raw)
To: 'Lennart Borgman', 'Stefan Monnier'
Cc: 'K. Richard Pixley', 7771
> 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
^ permalink raw reply [flat|nested] 47+ messages in thread
* bug#7771: 23.1; can't turn off font-lock-mode globally
2011-01-03 17:29 ` Drew Adams
@ 2011-01-03 17:32 ` Lennart Borgman
2011-01-03 17:40 ` Drew Adams
0 siblings, 1 reply; 47+ messages in thread
From: Lennart Borgman @ 2011-01-03 17:32 UTC (permalink / raw)
To: Drew Adams; +Cc: K. Richard Pixley, 7771
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?
^ permalink raw reply [flat|nested] 47+ messages in thread
* bug#7771: 23.1; can't turn off font-lock-mode globally
2011-01-03 17:32 ` Lennart Borgman
@ 2011-01-03 17:40 ` Drew Adams
0 siblings, 0 replies; 47+ messages in thread
From: Drew Adams @ 2011-01-03 17:40 UTC (permalink / raw)
To: 'Lennart Borgman'; +Cc: 'K. Richard Pixley', 7771
> > 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.
^ permalink raw reply [flat|nested] 47+ messages in thread
* bug#7771: 23.1; can't turn off font-lock-mode globally
2011-01-03 16:00 ` Drew Adams
@ 2011-01-03 18:01 ` Eli Zaretskii
2011-01-03 18:09 ` Drew Adams
0 siblings, 1 reply; 47+ messages in thread
From: Eli Zaretskii @ 2011-01-03 18:01 UTC (permalink / raw)
To: Drew Adams; +Cc: 7771
> 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)
^ permalink raw reply [flat|nested] 47+ messages in thread
* bug#7771: 23.1; can't turn off font-lock-mode globally
2011-01-03 18:01 ` Eli Zaretskii
@ 2011-01-03 18:09 ` Drew Adams
2011-01-03 18:26 ` Eli Zaretskii
0 siblings, 1 reply; 47+ messages in thread
From: Drew Adams @ 2011-01-03 18:09 UTC (permalink / raw)
To: 'Eli Zaretskii'; +Cc: 7771
> 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).
^ permalink raw reply [flat|nested] 47+ messages in thread
* bug#7771: 23.1; can't turn off font-lock-mode globally
2011-01-03 18:09 ` Drew Adams
@ 2011-01-03 18:26 ` Eli Zaretskii
0 siblings, 0 replies; 47+ messages in thread
From: Eli Zaretskii @ 2011-01-03 18:26 UTC (permalink / raw)
To: Drew Adams; +Cc: 7771
> 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.
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: bug#7771: 23.1; can't turn off font-lock-mode globally
[not found] ` <mailman.10.1294043026.27854.bug-gnu-emacs@gnu.org>
@ 2011-01-03 18:33 ` K. Richard Pixley
0 siblings, 0 replies; 47+ messages in thread
From: K. Richard Pixley @ 2011-01-03 18:33 UTC (permalink / raw)
To: bug-gnu-emacs
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
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: bug#7771: 23.1; can't turn off font-lock-mode globally
[not found] ` <mailman.1.1294062865.25287.bug-gnu-emacs@gnu.org>
@ 2011-01-03 18:38 ` K. Richard Pixley
0 siblings, 0 replies; 47+ messages in thread
From: K. Richard Pixley @ 2011-01-03 18:38 UTC (permalink / raw)
To: bug-gnu-emacs
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
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: bug#7771: 23.1; can't turn off font-lock-mode globally
[not found] ` <mailman.1.1294073635.27149.bug-gnu-emacs@gnu.org>
@ 2011-01-03 18:40 ` K. Richard Pixley
2011-01-03 19:52 ` Eli Zaretskii
0 siblings, 1 reply; 47+ messages in thread
From: K. Richard Pixley @ 2011-01-03 18:40 UTC (permalink / raw)
To: bug-gnu-emacs
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
^ permalink raw reply [flat|nested] 47+ messages in thread
* bug#7771: 23.1; can't turn off font-lock-mode globally
2011-01-03 18:40 ` K. Richard Pixley
@ 2011-01-03 19:52 ` Eli Zaretskii
2011-01-03 20:29 ` K. Richard Pixley
0 siblings, 1 reply; 47+ messages in thread
From: Eli Zaretskii @ 2011-01-03 19:52 UTC (permalink / raw)
To: K. Richard Pixley; +Cc: bug-gnu-emacs
> 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"?
^ permalink raw reply [flat|nested] 47+ messages in thread
* bug#7771: 23.1; can't turn off font-lock-mode globally
2011-01-03 19:52 ` Eli Zaretskii
@ 2011-01-03 20:29 ` K. Richard Pixley
2011-01-03 20:39 ` Eli Zaretskii
[not found] ` <mailman.3.1294088031.614.bug-gnu-emacs@gnu.org>
0 siblings, 2 replies; 47+ messages in thread
From: K. Richard Pixley @ 2011-01-03 20:29 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: bug-gnu-emacs
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
^ permalink raw reply [flat|nested] 47+ messages in thread
* bug#7771: 23.1; can't turn off font-lock-mode globally
2011-01-03 20:29 ` K. Richard Pixley
@ 2011-01-03 20:39 ` Eli Zaretskii
2011-01-03 21:02 ` Lennart Borgman
[not found] ` <mailman.3.1294088031.614.bug-gnu-emacs@gnu.org>
1 sibling, 1 reply; 47+ messages in thread
From: Eli Zaretskii @ 2011-01-03 20:39 UTC (permalink / raw)
To: K. Richard Pixley; +Cc: bug-gnu-emacs
> 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.
^ permalink raw reply [flat|nested] 47+ messages in thread
* bug#7771: 23.1; can't turn off font-lock-mode globally
2011-01-03 20:39 ` Eli Zaretskii
@ 2011-01-03 21:02 ` Lennart Borgman
2011-01-03 21:30 ` K. Richard Pixley
0 siblings, 1 reply; 47+ messages in thread
From: Lennart Borgman @ 2011-01-03 21:02 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: K. Richard Pixley, bug-gnu-emacs
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?
^ permalink raw reply [flat|nested] 47+ messages in thread
* bug#7771: 23.1; can't turn off font-lock-mode globally
2011-01-03 21:02 ` Lennart Borgman
@ 2011-01-03 21:30 ` K. Richard Pixley
2011-01-03 22:04 ` Lennart Borgman
0 siblings, 1 reply; 47+ messages in thread
From: K. Richard Pixley @ 2011-01-03 21:30 UTC (permalink / raw)
To: Lennart Borgman; +Cc: bug-gnu-emacs
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".
^ permalink raw reply [flat|nested] 47+ messages in thread
* bug#7771: 23.1; can't turn off font-lock-mode globally
2011-01-03 21:30 ` K. Richard Pixley
@ 2011-01-03 22:04 ` Lennart Borgman
2011-01-03 22:14 ` K. Richard Pixley
0 siblings, 1 reply; 47+ messages in thread
From: Lennart Borgman @ 2011-01-03 22:04 UTC (permalink / raw)
To: K. Richard Pixley; +Cc: bug-gnu-emacs
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.
^ permalink raw reply [flat|nested] 47+ messages in thread
* bug#7771: 23.1; can't turn off font-lock-mode globally
2011-01-03 22:04 ` Lennart Borgman
@ 2011-01-03 22:14 ` K. Richard Pixley
0 siblings, 0 replies; 47+ messages in thread
From: K. Richard Pixley @ 2011-01-03 22:14 UTC (permalink / raw)
To: Lennart Borgman; +Cc: bug-gnu-emacs
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
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: bug#7771: 23.1; can't turn off font-lock-mode globally
[not found] ` <mailman.1.1294028628.27854.bug-gnu-emacs@gnu.org>
@ 2011-01-03 22:23 ` K. Richard Pixley
2011-01-04 4:05 ` Eli Zaretskii
0 siblings, 1 reply; 47+ messages in thread
From: K. Richard Pixley @ 2011-01-03 22:23 UTC (permalink / raw)
To: bug-gnu-emacs
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
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: bug#7771: 23.1; can't turn off font-lock-mode globally
[not found] ` <mailman.3.1294088031.614.bug-gnu-emacs@gnu.org>
@ 2011-01-03 22:27 ` K. Richard Pixley
0 siblings, 0 replies; 47+ messages in thread
From: K. Richard Pixley @ 2011-01-03 22:27 UTC (permalink / raw)
To: bug-gnu-emacs
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
^ permalink raw reply [flat|nested] 47+ messages in thread
* bug#7771: 23.1; can't turn off font-lock-mode globally
2011-01-03 22:23 ` K. Richard Pixley
@ 2011-01-04 4:05 ` Eli Zaretskii
2011-01-04 4:21 ` K. Richard Pixley
0 siblings, 1 reply; 47+ messages in thread
From: Eli Zaretskii @ 2011-01-04 4:05 UTC (permalink / raw)
To: K. Richard Pixley; +Cc: bug-gnu-emacs
> 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?
^ permalink raw reply [flat|nested] 47+ messages in thread
* bug#7771: 23.1; can't turn off font-lock-mode globally
2011-01-04 4:05 ` Eli Zaretskii
@ 2011-01-04 4:21 ` K. Richard Pixley
0 siblings, 0 replies; 47+ messages in thread
From: K. Richard Pixley @ 2011-01-04 4:21 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: bug-gnu-emacs
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
^ permalink raw reply [flat|nested] 47+ messages in thread
end of thread, other threads:[~2011-01-04 4:21 UTC | newest]
Thread overview: 47+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-01-02 19:17 bug#7771: 23.1; can't turn off font-lock-mode globally K. Richard Pixley
2011-01-02 22:56 ` Leo
2011-01-02 23:19 ` K. Richard Pixley
2011-01-03 8:48 ` Leo
2011-01-02 23:49 ` Stefan Monnier
2011-01-03 0:27 ` K. Richard Pixley
2011-01-03 3:55 ` Stefan Monnier
2011-01-03 5:57 ` Glenn Morris
2011-01-03 6:00 ` Glenn Morris
[not found] ` <mailman.4.1294035825.27854.bug-gnu-emacs@gnu.org>
2011-01-03 6:56 ` K. Richard Pixley
2011-01-03 8:13 ` Drew Adams
2011-01-03 16:42 ` Lennart Borgman
2011-01-03 17:29 ` Drew Adams
2011-01-03 17:32 ` Lennart Borgman
2011-01-03 17:40 ` Drew Adams
[not found] ` <mailman.1.1294073635.27149.bug-gnu-emacs@gnu.org>
2011-01-03 18:40 ` K. Richard Pixley
2011-01-03 19:52 ` Eli Zaretskii
2011-01-03 20:29 ` K. Richard Pixley
2011-01-03 20:39 ` Eli Zaretskii
2011-01-03 21:02 ` Lennart Borgman
2011-01-03 21:30 ` K. Richard Pixley
2011-01-03 22:04 ` Lennart Borgman
2011-01-03 22:14 ` K. Richard Pixley
[not found] ` <mailman.3.1294088031.614.bug-gnu-emacs@gnu.org>
2011-01-03 22:27 ` K. Richard Pixley
[not found] ` <mailman.1.1294028628.27854.bug-gnu-emacs@gnu.org>
2011-01-03 22:23 ` K. Richard Pixley
2011-01-04 4:05 ` Eli Zaretskii
2011-01-04 4:21 ` K. Richard Pixley
2011-01-03 0:29 ` K. Richard Pixley
2011-01-03 1:55 ` Glenn Morris
2011-01-03 3:21 ` Lennart Borgman
2011-01-03 13:04 ` Eli Zaretskii
[not found] ` <mailman.30.1294025024.15403.bug-gnu-emacs@gnu.org>
2011-01-03 4:10 ` K. Richard Pixley
2011-01-03 5:34 ` Stefan Monnier
2011-01-03 6:52 ` K. Richard Pixley
2011-01-03 8:13 ` Drew Adams
2011-01-03 13:43 ` Eli Zaretskii
2011-01-03 16:00 ` Drew Adams
2011-01-03 18:01 ` Eli Zaretskii
2011-01-03 18:09 ` Drew Adams
2011-01-03 18:26 ` Eli Zaretskii
[not found] ` <mailman.1.1294062865.25287.bug-gnu-emacs@gnu.org>
2011-01-03 18:38 ` K. Richard Pixley
[not found] ` <mailman.10.1294043026.27854.bug-gnu-emacs@gnu.org>
2011-01-03 18:33 ` K. Richard Pixley
[not found] ` <mailman.22.1294021456.15403.bug-gnu-emacs@gnu.org>
2011-01-03 4:14 ` K. Richard Pixley
2011-01-03 0:31 ` K. Richard Pixley
2011-01-03 1:20 ` K. Richard Pixley
2011-01-03 1:54 ` Glenn Morris
2011-01-03 2:08 ` Glenn Morris
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.