GNU bug report logs - #2459
22.2.1: global-font-lock-mode does not turn off colors: ido.el, minibuffer prompt

Previous Next

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

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

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

From: Jari Aalto <jari.aalto <at> cante.net>
To: Emacs bug BTS <submit <at> debbugs.gnu.org>
Subject: 22.2.1: global-font-lock-mode does not turn off colors: ido.el, minibuffer prompt
Date: Tue, 24 Feb 2009 13:54:18 +0200

TEST

    emacs -Q -nw
    M-x ido-mode
    C-x C-f ~/   <notice the completions; in color>

    C-g
    M-x global-font-lock-mode <turn off>
    C-x C-f ~/   <notice the completions; *still* in color>

PROBLEMS

    After global-font-lock-mode is turned off:

    - ido-mode still displays completions in color.
    - Minibuffer prompt's text is still displayed in color.

If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
If you would like to further debug the crash, please read the file
/usr/share/emacs/22.2/etc/DEBUG for instructions.


In GNU Emacs 22.2.1 (x86_64-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2008-11-10 on excelsior, 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/emacs22:/etc/emacs:/usr/local/share/emacs/22.2/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/22.2/site-lisp:/usr/share/emacs/site-lisp:/usr/share/emacs/22.2/leim' '--with-x=yes' '--with-x-toolkit=athena' '--with-toolkit-scroll-bars' 'build_alias=x86_64-linux-gnu' 'host_alias=x86_64-linux-gnu' 'CFLAGS=-DDEBIAN -g -O2' 'LDFLAGS=-g' 'CPPFLAGS=''

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

From: Glenn Morris <rgm <at> gnu.org>
To: Jari Aalto <jari.aalto <at> cante.net>
Cc: 2459 <at> debbugs.gnu.org
Subject: Re: bug#2459: 22.2.1: global-font-lock-mode does not turn off colors: ido.el, minibuffer prompt
Date: Tue, 24 Feb 2009 13:17:46 -0500

severity 2459 wishlist
stop

Jari Aalto wrote:

>     After global-font-lock-mode is turned off:
>
>     - ido-mode still displays completions in color.
>     - Minibuffer prompt's text is still displayed in color.

These features, and several other places that use colour, are not
implemented using font-lock, so toggling global-font-lock-mode has no
effect. In this specific case, you can set ido-use-faces and customize
the minibuffer-prompt face.

AFAIK there is no simple way to say "give me an entirely monochromatic
Emacs".

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

From: Jari Aalto <jari.aalto <at> cante.net>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 2459 <at> debbugs.gnu.org
Subject: Re: bug#2459: 22.2.1: global-font-lock-mode does not turn off colors: ido.el, minibuffer prompt
Date: Tue, 24 Feb 2009 21:31:49 +0200

Glenn Morris <rgm <at> gnu.org> writes:

> Jari Aalto wrote:
>
>>     After global-font-lock-mode is turned off:
>>
>>     - ido-mode still displays completions in color.
>>     - Minibuffer prompt's text is still displayed in color.
>
> These features, and several other places that use colour, are not
> implemented using font-lock, so toggling global-font-lock-mode has no
> effect. In this specific case, you can set ido-use-faces and customize
> the minibuffer-prompt face.

Perhaps those can be teach to obey global-font-lock-mode settings.
It is not feasible to have to configure those separately.

> AFAIK there is no simple way to say "give me an entirely monochromatic
> Emacs".

It used to.

Jari

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

From: Juri Linkov <juri <at> jurta.org>
To: Jari Aalto <jari.aalto <at> cante.net>
Cc: 2459 <at> debbugs.gnu.org, Glenn Morris <rgm <at> gnu.org>
Subject: Re: bug#2459: 22.2.1: global-font-lock-mode does not turn off colors: ido.el, minibuffer prompt
Date: Tue, 24 Feb 2009 21:56:52 +0200

>>>     After global-font-lock-mode is turned off:
>>>     - ido-mode still displays completions in color.
>>>     - Minibuffer prompt's text is still displayed in color.
>>
>> These features, and several other places that use colour, are not
>> implemented using font-lock, so toggling global-font-lock-mode has no
>> effect. In this specific case, you can set ido-use-faces and customize
>> the minibuffer-prompt face.
>
> Perhaps those can be teach to obey global-font-lock-mode settings.
> It is not feasible to have to configure those separately.

Font-lock makes sense only for syntax-based highlighting.

>> AFAIK there is no simple way to say "give me an entirely monochromatic
>> Emacs".
>
> It used to.

Something along the lines is a simple way to give a monochromatic Emacs.
Perhaps we should create a new function that will do this depending on
an option.

(defun my-faces-fix (&optional frame)
  "Fix defined faces."
  (interactive)
  ;; Check if this function is called by `custom-define-hook' from
  ;; `custom-declare-face' where the variable `face' is bound locally.
  (when (boundp 'face)
    (dolist (face (face-list))
      (unless (string-match "^mode-line" (symbol-name face))
        ;; Reset all face attributes
        (modify-face face)))))

;; 1. Fix existing faces
(let ((face t)) (my-faces-fix))

;; 2. Call `my-faces-fix' every time some new face gets defined
(add-to-list 'custom-define-hook 'my-faces-fix)

-- 
Juri Linkov
http://www.jurta.org/emacs/

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

From: Richard M Stallman <rms <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>, 2459 <at> debbugs.gnu.org
Cc: jari.aalto <at> cante.net, 2459 <at> debbugs.gnu.org
Subject: Re: bug#2459: 22.2.1: global-font-lock-mode does not turn off colors:
	ido.el, minibuffer prompt
Date: Wed, 25 Feb 2009 10:53:29 -0500

    These features, and several other places that use colour, are not
    implemented using font-lock, so toggling global-font-lock-mode has no
    effect. In this specific case, you can set ido-use-faces and customize
    the minibuffer-prompt face.

This sort of problem is easy to fix; we already have a mechanism for
it.  The mode should set `font-lock-face' properties instead of `face'
properties.  That will make the right thing happen.

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

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 2459 <at> debbugs.gnu.org, Jari Aalto <jari.aalto <at> cante.net>
Subject: Re: bug#2459: 22.2.1: global-font-lock-mode does not turn off colors: ido.el, minibuffer prompt
Date: Wed, 25 Feb 2009 11:49:07 -0500

> These features, and several other places that use colour, are not
> implemented using font-lock, so toggling global-font-lock-mode has no
> effect. In this specific case, you can set ido-use-faces and customize
> the minibuffer-prompt face.

Several places now use the `font-lock-face' property so that toggling
font-lock indeed also toggles the corresponding highlighting.  Maybe we
should use that a bit more.

This said, font-lock has traditionally been used for the highlighting of
buffer's contents, as opposed to modelines, menu-bars, and minibuffers.

What Jari seems to be suggesting is to let the minibuffer highlighting
obey font-lock as well.  Maybe it's a good idea.  I do not know.


        Stefan

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

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Stefan Monnier'" <monnier <at> IRO.UMontreal.CA>,
        <2459 <at> debbugs.gnu.org>, "'Glenn Morris'" <rgm <at> gnu.org>
Cc: "'Jari Aalto'" <jari.aalto <at> cante.net>
Subject: RE: bug#2459: 22.2.1: global-font-lock-mode does not turn off colors:ido.el, minibuffer prompt
Date: Wed, 25 Feb 2009 09:24:04 -0800

> > These features, and several other places that use colour, are not
> > implemented using font-lock, so toggling global-font-lock-mode
> > has no effect. In this specific case, you can set ido-use-faces 
> > and customize the minibuffer-prompt face.
> 
> Several places now use the `font-lock-face' property so that toggling
> font-lock indeed also toggles the corresponding highlighting. 
> Maybe we should use that a bit more.
> 
> This said, font-lock has traditionally been used for the highlighting
> of buffer's contents, as opposed to modelines, menu-bars, and 
> minibuffers.
> 
> What Jari seems to be suggesting is to let the minibuffer highlighting
> obey font-lock as well.  Maybe it's a good idea.  I do not know.

My 2c: It's not a good idea. That would dilute the meaning of the concept
font-lock and its behavior. It would mean that you could not turn on/off
font-lock highlighting independently of the highlighting of such features.

The use case seems to be only to turn off *all* highlighting. We should find a
good way to handle that particular use case. Equating all highlighting to
font-lock highlighting, just to respond to this use case, would be using a
sledge hammer to kill a fly - a step backward.

This is not the first time someone has complained about not being able to turn
off the highlighting added by such things as the minibuffer prompt. This is a
reaction to our adding that highlighting, and enabling it by default. It has
nothing per se to do with font-lock and syntax highlighting.

TRT is to look for an easy way for a user to turn off *all* highlighting (but
without affecting other face properties, presumably) - without messing with
font-lock behavior.

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

From: Jari Aalto <jari.aalto <at> tamk.fi>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: "'Stefan Monnier'" <monnier <at> IRO.UMontreal.CA>,
        <2459 <at> debbugs.gnu.org>, "'Glenn Morris'" <rgm <at> gnu.org>,
        "'Jari Aalto'" <jari.aalto <at> cante.net>
Subject: Re: bug#2459: 22.2.1: global-font-lock-mode does not turn off colors:ido.el, minibuffer prompt
Date: Thu, 26 Feb 2009 16:16:14 +0200

> "Drew Adams" <drew.adams <at> oracle.com> writes:
> The use case seems to be only to turn off *all* highlighting. We should find a
> good way to handle that particular use case. Equating all highlighting to
> font-lock highlighting, just to respond to this use case, would be using a
> sledge hammer to kill a fly - a step backward.

It's natural that people have years trained themselves to use:

  M-x global-font-lock-mode

to turn on and off colors. Globally. From user's M-x perspective, the
font-lock is synonym for controlling the "colors", whether in technical
level the implementation and use of font-lock may differ.

> Richard M Stallman <rms <at> gnu.org> writes:
> This sort of problem is easy to fix; we already have a mechanism for
> it.  The mode should set `font-lock-face' properties instead of `face'
> properties.  That will make the right thing happen.

That'd be welcomed

Thanks,
Jari

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

From: Richard M Stallman <rms <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>, 2459 <at> debbugs.gnu.org
Cc: monnier <at> IRO.UMontreal.CA, 2459 <at> debbugs.gnu.org, rgm <at> gnu.org,
        jari.aalto <at> cante.net
Subject: Re: bug#2459: 22.2.1: global-font-lock-mode does not turn off
	colors:ido.el, minibuffer prompt
Date: Thu, 26 Feb 2009 14:25:42 -0500

    > This said, font-lock has traditionally been used for the highlighting
    > of buffer's contents, as opposed to modelines, menu-bars, and 
    > minibuffers.

I agree that we should maintain this distinction -- control of display
outside of ordinary buffer contents should not be controlled by Font
Lock mode as such.

Previous Next

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