* 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 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-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-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
* 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
[parent not found: <mailman.4.1294035825.27854.bug-gnu-emacs@gnu.org>]
* 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 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-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
[parent not found: <mailman.1.1294073635.27149.bug-gnu-emacs@gnu.org>]
* 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
[parent not found: <mailman.3.1294088031.614.bug-gnu-emacs@gnu.org>]
* 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
[parent not found: <mailman.1.1294028628.27854.bug-gnu-emacs@gnu.org>]
* 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
* 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
* 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-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: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 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
[parent not found: <mailman.30.1294025024.15403.bug-gnu-emacs@gnu.org>]
* 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
* 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 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
* 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 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 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
[parent not found: <mailman.1.1294062865.25287.bug-gnu-emacs@gnu.org>]
* 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
[parent not found: <mailman.10.1294043026.27854.bug-gnu-emacs@gnu.org>]
* 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
[parent not found: <mailman.22.1294021456.15403.bug-gnu-emacs@gnu.org>]
* 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-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 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
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 public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).