faces and face variables

faces and face variables

[Roland Winkler]

This is an issue that emerged from a discussion with Dan on
proced.el:

The code of proced.el has largely been inspired by the old code of
dired.el. But sometimes this strategy has some pitfalls:

dired.el defines both the faces it uses (like dired-header) and it has
face variables like dired-header-face. Is this strategy still
appropriate for new code? Or is it better to use the faces only?

Font-lock also has such variables, and the code contains the comment
that these variables

  "give users another mechanism for changing face appearance."

If face variables are not considered appropriate anymore and their
use is not recommended anymore, it might help to have a more
definite comment on this issue in font-lock.el (i.e., remove the
above remark and say *only* that these variables are kept for
backward compatibility). Otherwise, users might expect to find this
"feature" for other faces, too.

Thanks,

Roland

PS: I searched emacs-devel for old discussions of this topic, but I
wasn't successful.

Re: faces and face variables

[Glenn Morris]

"Roland Winkler" wrote:

> dired.el defines both the faces it uses (like dired-header) and it has
> face variables like dired-header-face. Is this strategy still
> appropriate for new code? Or is it better to use the faces only?

E.g.

http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg01589.html

    ...variables pointing to faces are generally deprecated unless
    maybe they're used in font-lock rules where avoiding the ' can be
    marginally convenient.

http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg01660.html

    Maybe we should work harder to document the fact that we do not
    want such variables.

Echoing your suggestion.

> Font-lock also has such variables, and the code contains the comment
> that these variables

Don't use font-lock as an example, it's a law unto itself for
historical reasons.

Re: faces and face variables

[Roland Winkler]

On Sat Sep 13 2008 Glenn Morris wrote:
> http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg01660.html
> 
>     Maybe we should work harder to document the fact that we do not
>     want such variables.
> 
> Echoing your suggestion.

That message continues:

  Where would such info have reached you better?

I looked up defface in the elisp manual in order to find a hint. But
there was none. So I suggest to mention there (or include a link
pointing elsewhere) that such variables are deprecated.

> > Font-lock also has such variables, and the code contains the comment
> > that these variables
> 
> Don't use font-lock as an example, it's a law unto itself for
> historical reasons.

As I said, the starting point for me was dired.el. Certainly, that
code has its own history. But the bottom line is that there is more
than one source for the "wrong inspiration" and it would be good if
at some prominent point it was stated clearly what today's
recommended strategy is (despite historical counter examples).

Are there, besides font-lock and dired, other fossils in GNU emacs
that still use such variables?

Roland

RE: faces and face variables

[Drew Adams]

> I looked up defface in the elisp manual in order to find a hint. But
> there was none. So I suggest to mention there (or include a link
> pointing elsewhere) that such variables are deprecated.
> 
> > > Font-lock also has such variables, and the code contains 
> > > the comment that these variables
> > 
> > Don't use font-lock as an example, it's a law unto itself for
> > historical reasons.
> 
> As I said, the starting point for me was dired.el. Certainly, that
> code has its own history. But the bottom line is that there is more
> than one source for the "wrong inspiration" and it would be good if
> at some prominent point it was stated clearly what today's
> recommended strategy is (despite historical counter examples).
> 
> Are there, besides font-lock and dired, other fossils in GNU emacs
> that still use such variables?

Dunno, maybe there are. If so, they should be removed.

But I don't agree that face variables are or should be "deprecated" or that all
uses of face variables are necessarily "fossils". 

Yes, the message to users should be that you normally do not want to create face
variables - use faces directly instead. But that doesn't mean that face
variables should never be used. This is what I wrote last February (thread
"Default font 'default have no corresponding variable"):

> > Maybe we should work harder to document the fact that we do not want
> > such variables.  Where would such info have reached you better?
> > 
> > How about if we put comments in and among the variable 
> > definitions in font-lock.el saying not to imitate that practice.
> 
> I think the place to discuss this is in the Elisp manual, in 
> one of the sections about faces. This is really about
> understanding what a face is, IMO.
> 
> FWIW, I have a slightly different take on the practice to 
> recommend and the reasons to give for that recommendation. 
> 
> I agree with the recommended practice of defining and using 
> faces, not face variables, in general - and I follow it.
> However, I don't agree that the only case for defining and
> using face variables is the legacy case of the font-lock code. 
> 
> The use case I see, which, again, is not the usual case, is 
> when you want to make it easy for code to temporarily use a
> particular face. It is very easy for some code to dynamically
> bind a face variable and cause subsequently executed code to
> use that face. Getting the same effect with faces (without
> a face variable) can make for uglier code, IMO.
> 
> Just one opinion. I'm not interested in arguing about that.
> I agree that we should make it clear that you generally
> should not define face variables. And I think the place to
> communicate that guideline is the Elisp doc, not just
> comments in the code.

FWIW, Richard replied:

> I agree that this would be a good reason to have such a variable.
> Whether there are such cases, I don't know.

What's important, I think, is to propagate the general recommendation together
with its rationale. That is, help users understand what faces are, which is what
this is about. If all we provide is a catechism, then all we can expect is rote
learning with little understanding.

IOW, let's not confuse the effort to remove such fossils from the Emacs code
with the idea that no one should ever use face variables. Use them in the (rare)
cases where they are useful; don't use them otherwise.

Re: faces and face variables

[Miles Bader]

"Drew Adams" <drew.adams@oracle.com> writes:
> But I don't agree that face variables are or should be "deprecated" or that all
> uses of face variables are necessarily "fossils". 

99% of "face variables" in existing code are not used the way you
described, but instead are pointless frippery.

As richard said, there can be cases where a variable referring to a face
is called for -- but there are almost _always_ considered exceptions to
any given rule; that does not make the rule wrong for the general case.

-Miles

-- 
Dictionary, n.  A malevolent literary device for cramping the growth of
a language and making it hard and inelastic. This dictionary, however,
is a most useful work.

RE: faces and face variables

[Drew Adams]

> > But I don't agree that face variables are or should be 
> > "deprecated" or that all uses of face variables are
> > necessarily "fossils". 
> 
> 99% of "face variables" in existing code are not used the way you
> described, but instead are pointless frippery.

I never suggested otherwise. In fact, I said the same thing.
And I said clearly that all such fossils should be removed
from the existing code.

Again:

 IOW, let's not confuse the effort to remove such fossils
 from the Emacs code with the idea that no one should ever
 use face variables. Use them in the (rare) cases where
 they are useful; don't use them otherwise.

> As richard said, there can be cases where a variable 
> referring to a face is called for -- but there are almost
> _always_ considered exceptions to any given rule; that does not
> make the rule wrong for the general case.

Again, that's just what I said. Please reread. No one has
claimed that the rule is "wrong for the general case".

And Richard didn't say that, BTW - I did. He merely
acknowledged that there might be such cases, and that the
particular use case I pointed out is reasonable.

The point is that we should not just provide the rule, but
also explain it. And to do that in the Elisp manual, not just
in some source code comments somewhere.

Proced's display/handling of process trees: request for feedback

[Roland Winkler]

 Sun Dec 28 2008 Roland Winkler wrote:
On Mon Sep 8 2008 Dan Nicolaescu wrote:
> - And one wishlist item: it would be great to have a tree view of the
>   processes, like "pstree" does.

Request for feedback for Proced's display and handling of process trees:

I played with a `*Proced Tree*' buffer and found it a bit confusing
to have two separate buffers. Also, I found it complicated to ensure
that this buffer is synchronized with the corresponding *Proced*
buffer. So instead I've added a tree column that can be toggled
(toggling is bound to T). Is the current approach useful?

Is the format of the tree column in the process listing clear?

Currently, there are two commands to operate on processes based on
the tree structure, proced-mark-parents and proced-mark-children
bound to P and C. Would it be useful to have more commands?

Any comments and suggestions for improvements are appreciated.

Roland