bug#5502: compile.el uses non-mode-line faces in the mode line

bug#5502: compile.el uses non-mode-line faces in the mode line

[Karl Berry]

In Emacs 23.1[.92], compile.el uses non-mode-line faces to propertize
text used in the mode line.  My goal is to have inverse video in the
mode line, and regular text only (no underlines, fake bold, etc.) in the
buffer contents.

To reproduce:
emacs -nw --no-site --no-init -l inv.el  # where invtest.el is appended
M-x compile RET
[backspace to wipe out the "make -k", then] false RET

Observe that the compilation status in the mode line is in "regular"
video, unlike the rest of the mode line.

Thanks,
Karl

Here is invtest.el:

(setq compilation-mode-hook 'k-inverse-video-hook)
(defun k-inverse-video-hook ()
  (set-face-attribute 'compilation-info    nil :inverse-video nil)
  (set-face-attribute 'compilation-warning nil :inverse-video nil)
  (set-face-attribute 'compilation-error   nil :inverse-video nil)
)


P.S. I don't suppose this is news to you, but it is apparently coming
from the following three pieces of compile.el.  If the mode line stuff
used face names like mode-line-compilation-{warning,info,error}, which
could default to the same values they get now, then (I surmise) they
could be controlled independently.  Everything else I've run across so
far does use face names mode-line-* for text that goes in the mode line.

	      (setq mode-line-process
		    (list (propertize ":%s" 'face 'compilation-warning)))
..
	  (setq mode-line-process
		(list (propertize ":run" 'face 'compilation-warning)))
..
	    (propertize out-string
			'help-echo msg 'face (if (> exit-status 0)
						 'compilation-error
					       'compilation-info))))

bug#5502: compile.el uses non-mode-line faces in the mode line

[Stefan Monnier]

> Here is invtest.el:

> (setq compilation-mode-hook 'k-inverse-video-hook)
> (defun k-inverse-video-hook ()
>   (set-face-attribute 'compilation-info    nil :inverse-video nil)
>   (set-face-attribute 'compilation-warning nil :inverse-video nil)
>   (set-face-attribute 'compilation-error   nil :inverse-video nil)
> )

Why do you set inverse-video to nil?  If you set it to `unspecified'
instead, it should work right.


        Stefan

bug#5502: compile.el uses non-mode-line faces in the mode line

[Karl Berry]

Hi Stefan,

    Why do you set inverse-video to nil?  

My real goal, as I mentioned, is to have inverse video in mode lines,
and all face attributes turned off in buffer contents in tty emacs.
(The behavior of Emacs for 20+ years, until Emacs 22 "improved" faces by
making them apply to tty windows, with no way to get the old behavior.
Sigh.)

I can give you more complex code if you want (ie, the code I'm actually
trying to use).  This minimal example was only intended to show that the
same compilation faces were being used in the mode line and buffer
contents, which other parts of Emacs do not do.

Thus, if I turn off faces for the buffer contents, they stay turned off
in the mode line, and vice versa.  If different faces were available,
they could be controlled independently.  (As an alternative, I suppose I
can try to defadvise mode line generation, or some such.)

    If you set it to `unspecified' instead, it should work right.

Unfortunately, it didn't help me do what I'm trying to do.

Thanks,
Karl

bug#5502: compile.el uses non-mode-line faces in the mode line

[Stefan Monnier]

>     Why do you set inverse-video to nil?  

> My real goal, as I mentioned, is to have inverse video in mode lines,
> and all face attributes turned off in buffer contents in tty emacs.
> (The behavior of Emacs for 20+ years, until Emacs 22 "improved" faces by
> making them apply to tty windows, with no way to get the old behavior.
> Sigh.)

> I can give you more complex code if you want (ie, the code I'm actually
> trying to use).  This minimal example was only intended to show that the
> same compilation faces were being used in the mode line and buffer
> contents, which other parts of Emacs do not do.

> Thus, if I turn off faces for the buffer contents, they stay turned off
> in the mode line, and vice versa.  If different faces were available,
> they could be controlled independently.  (As an alternative, I suppose I
> can try to defadvise mode line generation, or some such.)

>     If you set it to `unspecified' instead, it should work right.

> Unfortunately, it didn't help me do what I'm trying to do.

Why not?  "turning a face off" is done by setting its attributes to
`unspecified' rather than to nil.


        Stefan

bug#5502: compile.el uses non-mode-line faces in the mode line

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Unfortunately, it didn't help me do what I'm trying to do.
>
> Why not?  "turning a face off" is done by setting its attributes to
> `unspecified' rather than to nil.

This seems to have been resolved, so I'm closing this report.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

bug#5502: compile.el uses non-mode-line faces in the mode line

[Karl Berry]

    This seems to have been resolved, so I'm closing this report.

1. As I reported originally, it still seems just basically wrong to me,
as a matter of implementation design, to use face for the mode line
whose name does not start with the prefix "mode-line".  But since
obviously you don't share my opinion, there's nothing more to say there.

2. I still wish there was a supported way to simply turn off all
colorization, fontification, whatever you want to call it, without
affecting functionality.  All those color changes are just a distraction
for me.  I just want black and white, the way Emacs was for many years.
But obviously again I'm the only dinosaur who feels like this, so I
guess again that's just the way it'll stay.

3. In any case, Juri's latest tidbit of additional information does do
the job to make my mode line entirely inverse video again, so fine, the
report can stay closed.  Life goes on.  (Thanks again Juri, I'd be
nowhere close to using e23 without you.)

karl

bug#5502: compile.el uses non-mode-line faces in the mode line

[Glenn Morris]

Karl Berry wrote:

> 2. I still wish there was a supported way to simply turn off all
> colorization, fontification, whatever you want to call it, without
> affecting functionality.  All those color changes are just a distraction
> for me.  I just want black and white, the way Emacs was for many years.
> But obviously again I'm the only dinosaur who feels like this, so I
> guess again that's just the way it'll stay.

Just for fun, I tried:

emacs -Q --eval '(defun display-color-p (&optional display) nil)'

How does that look to you...?

bug#5502: compile.el uses non-mode-line faces in the mode line

[Karl Berry]

(Back on http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5502.)

    rgm> Just for fun, I tried:
    emacs -Q --eval '(defun display-color-p (&optional display) nil)'
    How does that look to you...?

Glenn, thanks for trying, but ... not so great.  My initial attempt:
1) The "M-x " prompt is still in blue (not that that's such a big deal).
2) When I run M-x compile RET foo RET,
   the *compilation* and "exit[]" in the mode line are in bold.
   Also, in the buffer text, the stuff I've surrounded with ** is in
   bold:
  ...
  **/usr/local/gnu/bin/bash**: foo: command not found

  Compilation **exited abnormally** with code **127** at Sun Sep 25 10:09:48
  
With Juri's functions, at least the /usr/local/gnu/bin/bash is in
regular text, although the "exited abnormally" and "127" are still in
reverse video.

Which points out, again, the problem I was trying to report originally:
using the same face for text in the mode line and in the buffer text
makes it impossible to reliably make the mode line text reverse video
and the buffer text normal.  In 23.3, compilation-warning,
compilation-error, and compilation-info are used for both.  As far as I
can tell.


Stefan, regarding global-font-lock-mode: I'll try it again in 23.4 (or a
pretest if you've knowingly fixed things in this area).  Running:
$ emacs-23.3 -Q --eval '(global-font-lock-mode 0)'
- the *scratch* text is in red.
- the "M-x " prompt is in blue.
- running M-x compile RET foo RET has blue and red for the same text
  that I marked above, and red in the mode line.

Best,
karl

bug#5502: compile.el uses non-mode-line faces in the mode line

[Stefan Monnier]

> 2. I still wish there was a supported way to simply turn off all
> colorization, fontification, whatever you want to call it, without
> affecting functionality.

global-font-lock-mode is usually meant to be the way to get that.
As you know it doesn't work for everything (tho it does now work for
compile.el and derivatives (e.g. grep.el)), but at least for buffer
contents it generally should and when it doesn't it's usually a bug.

> All those color changes are just a distraction for me.  I just want
> black and white, the way Emacs was for many years.  But obviously
> again I'm the only dinosaur who feels like this, so I guess again
> that's just the way it'll stay.

For the mode-line/menu-bar/header-line and other such elements which are
intrinsically visually distinct, the answer is much less clear because
it's not clear what is meant by "turn off colorization".  I think what
it means depends on what was the first version of Emacs you used ;-)


        Stefan

bug#5502: compile.el uses non-mode-line faces in the mode line

[Karl Berry]

    global-font-lock-mode is usually meant to be the way to get that.
    As you know it doesn't work for everything

Uh huh.  I'll try again global-font-lock-mode again in the next release.
(And Glenn's attempt as soon as I have a chance, thanks Glenn.)

    For the mode-line/menu-bar/header-line and other such elements which are
    intrinsically visually distinct, the answer is much less clear because
    it's not clear what is meant by "turn off colorization".  I think what
    it means depends on what was the first version of Emacs you used ;-)

For mode-line, it doesn't depend on the version.  mode-line has always,
since day one, been in reverse video.  Otherwise the Emacs screen
becomes *completely* undifferentiated text, which isn't useful.  I don't
know what the latest global-font-lock-mode does, but I would urge in
principle that it keep the mode line in inverse video from the rest of
the text.  Otherwise all the same issues and frustrations would recur --
having to change certain faces and not others, etc.

If the question is what does reverse video mean, well, in the case of
black/white letters/background, the answer is clear :), and no other
cases are very interesting, so any reasonable answer will do.

As for header-line and menu-bar, I have no opinion since I don't use
them.  I don't even know what header-line is, shame on me.

Thanks,
karl

bug#5502: compile.el uses non-mode-line faces in the mode line

[Eli Zaretskii]

> Date: Sun, 17 Jul 2011 15:34:27 GMT
> From: karl@freefriends.org (Karl Berry)
> Cc: 5502@debbugs.gnu.org
> 
> I don't even know what header-line is, shame on me.

If you ever use the Emacs built-in Info reader, you do know: that's
that funny line that says "Next: Foo, Prev: Bar" etc. at the top of
the window.

bug#5502: compile.el uses non-mode-line faces in the mode line

[Juri Linkov]

>     If you set it to `unspecified' instead, it should work right.
>
> Unfortunately, it didn't help me do what I'm trying to do.

`compilation-error' inherits from `font-lock-warning-face',
so you have to reset its attribute to `unspecified' as well:

  (set-face-attribute 'compilation-error      nil :inverse-video 'unspecified)
  (set-face-attribute 'font-lock-warning-face nil :inverse-video 'unspecified)

Or when using `modify-face' every attribute should be `unspecified':

  (modify-face face 'unspecified 'unspecified 'unspecified 'unspecified
                    'unspecified 'unspecified 'unspecified)

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