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

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

[Jari Aalto]

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=''

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

[Glenn Morris]

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

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

[Emacs bug Tracking System]

Processing commands for control@emacsbugs.donarmstrong.com:

> severity 2459 wishlist
bug#2459: 22.2.1: global-font-lock-mode does not turn off colors: ido.el, minibuffer prompt
Severity set to `wishlist' from `normal'

> stop
Stopping processing here.

Please contact me if you need assistance.

Don Armstrong
(administrator, Emacs bugs database)

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

[Jari Aalto]

Glenn Morris <rgm@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

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

[Juri Linkov]

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

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

[Richard M Stallman]

    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.

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

[Stefan Monnier]

> 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

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

[Drew Adams]

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

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

[Jari Aalto]

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

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

[Richard M Stallman]

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