On Sun, Feb 6, 2011 at 9:11 AM, Drew Adams
<address@hidden> wrote:
T> One thing I would recommend doing, if possible, would be to
T> spend some time running emacs with a dark background and on a
T> tty. This would likely reveal how bad some default face
T> definitions are and let you see how tedious it is having to
T> customize lots of individual face definitions just to get ones
T> that work.
I'm not sure what your disagreements are with what I said. I
agree that poorly defined default face definitions are a real
problem. I even suggested that they are likely _the_ real
problem here.
I think our point of disagreement is small - it is really a matter of degrees. Your position is one I would characterise as representing a pure or strict view of inheritance and one I see as having a strong ideological and theoretical base. Mine is possibly chracterised as being more pragmatic and less pure or strict, possibly characterised as being more liberal.
There are also a number of assumptions and conclusions you ahve made regarding some of my points, which are incorrect. I will try to make my position with these clearer.
Given reasonable face defaults that work out of the box on
both dark and light backgrounds, I think many if not most
(perhaps all?) of the problems you cited go away. With faces
that just work by default, regardless of the background, there
is no need to "customize lots of individual face definitions
just to get ones that work".
Agreed. If all faces were well defined there would be no problem. However, the reality is that frequently they are not. My suggestions are based on the belief that this is because defining good default face settings is not easy, takes more effort than some developers want to expend, is difficult to do right as developers don't necessarily have access to all the environments involved and it may be unreasonable to expect all developers have the necessary knowledge and experience to know/identify a good default face setting. Therefore, my focus is on what we can do to make it easier for developers to do the right thing. One solution which I think would work towards this would be to develop a set of guidelines on how to identify and select appropriate faces to inherit from and pitfalls to avoid combined with requiring that faces are either fully defined or inherit from a core/base face which is fully defined.
I'm not arguing that faces with similar appearance should be linked via inheritance and I'm not arguing that existing fully defined faces should be converted to use inheritance.
The main point of disagreement concerns determining appropriate faces to inherit from. Your position is that inheritance should only be used to inherit from a face with the same/similar semantics/meaning as the child face. My argument is less restrictive. If a core face exists that has the same semantic meaning as the child face, then of course that is the obvious choice. However, if there are no core faces with the same semantic meaning I would rather have the face inherit from a fully defined face with a different semantic meaning, provided that does not cause confusion within the mode used by the child face, rather than have a face that is not fully defined.
I would go further and suggest that while you accept the use of inheritance provided the inheritance chain follows the same semantic meaning, you would prefer in general not to use inheritance even if a good candidate with the same semantic meaning does exist in the core set of fully defined faces. While I would never argue that developers should be forced to use inheritance, I would suggest this is the wrong approach. I believe inheritance should definitely be used when there is clear semantic equivalents within the core set because this will help ensure consistency in representation of semantically related items. For example, I currently have numerous definitions for 'hyperlink' type objects as well as clickable buttons. I would like objects of these types to have the same appearance in all modes. However, I like hyperlinks to be a specific colour, with underlining, bold and italic fonts. To achieve this (possibly unusual) appearance in a consistent manner, I have to customize multiple faces. However, if inheritance was used, I would only have to do this once.
If I understand your position regarding inheritance, you disagree with the concept of a child face inheriting from a semantically unrelated face because you feel doing so will lead to confusion and unexpected results because it 'muddies' the semantics of the inheritance and will cause unexpected/unwanted side effects when a core face definition is changed. I don't see it as being that straight-forward. I agree that badly chosen inheritance would cause problems - for example, having something that was not a clickable link inherit from the link face. On the other hand, core packages, such as dired, have been using inheritance from sematically unrelated faces for some time and I'm not aware it has caused problems. The dired-directory face inherits from font-lock-function-name-face. There is no 'semantic' link between these two faces, yet having this inheritance apparently works. Yes, if I change the value of font-lock-function-name-face, it will change the appearance of directory names in dired. However, in practice, this is rarely a problem. In fact, if your changing the face to make it fit better with some theme or to work better in your environment, it is likely that this change would fit with your overall objectives anyway.
One of the reasons I think this works is because the choice is unrelated and does not confuse contexts within the mode the face is used in. If dired had a face to represent function names, then using font-lock-function-name-face for directory names would be a bad idea. However, dired does not have such a context and therefore does not cause confusion within that mode. Furthermore, I don't believe it would cause confusion with modes that use font-lock-function-name-face for function names. The two modes are distinct enough that it is clear that a face with X attributes in dired is different to a face with the same attributes in completely unrelated modes, such as emacs-lisp-mode.
There are some other benefits to using inheritance in this manner. I think it is reasonable to suggest that all users have some underlying 'theme' they want to achieve with face settings. Some themes may seem unusual or even unpleasant, but there is usually some overriding pattern - faces are not selected randomly (I guess there may be some extreme cases where people might do this, but it isn't the 'norm'). Within any theme there is a finite set of usable faces i.e. faces that can be read, fit with the theme and are aesthetically acceptable. As we increase the number of individual face definitions, we also increase the number of faces with different names/meanings which have the same set of attributes as other unrelated faces.
If we assume two basic approaches, your pure inheritance model and my less rigid inheritance approach, we end up with two vary different situations when it comes to the user customizing faces to obtain their desired theme. Under your approach, they will need to customize a larger number of faces to obtain their desired outcome. However, under my approach, which is more likely to make greater use of inheritance because it is not restricted to only using semantically related faces, it is more probable that less faces will need to be defined.
Of course, we could probably achieve a better 'middle ground' with a larger, more comprehensive set of core/base faces as this would increase the likelihood that a child face can find a sematically related core/base face definition. I have nothing against this and included it as part of my suggestion on how to improve matters and reduce the number of poorly defined faces.
T> As I see it, we want to achieve four main goals. We want to
T> make it easier for developers to set appropriate defaults, we
T> want to get the best default possible for end users,
T> regardless of platform or light/dark background preferences,
T> we want to make it as easy as possible for end users to
T> customize their environment
Agree.
T> and we want to, if possible, avoid a proliferation of
T> different face definitions, especially when the definitions
T> don't really differ in anything other than name as this makes
T> customizing and theme definition more complex than it needs to
T> be.
Disagree, if by "don't really differ in anything other than
the name" you are referring only to the `defface' default
attribute values.
I am in favor of there being two faces instead of one, if
their use/meaning is different, even if their definitions
modulo the names are identical. In particular, this
facilitates separate customization.
I was actually thinking of faces that have the same meaning, different names and different default definitions. This is a growing problem. We end up with inconsistency between modes for faces representing the same type of object. It was not meant to mean faces that happen to have the same attribute sets. For example, I have a number of modes that have the same concept of a clickable 'button'. In some modes they look different to how buttons look in other modes. I want them to all look the same and have to customize them individually. This is what I meant by the proliferation of faces.
It avoids coupling that is not logical and not necessary.
Inheritance (hence coupling) based on physical attributes
(appearance) can perhaps occasionally be appropriate, but in
general it is a no-no.
Yes, where possible, inheritance should be used to link semantically related faces . However, linking semantically unrelated faces is not as bad in practice as you suggest and could be used to improve the end user expereince without causing the confusion you suggest. Yes, there are dangers, but there are also benefits which I think outweigh the downside of a strict inheritance approach, especially if there are only a few core/base fonts to inherit from.
(Names are generally indicative of meaning, but yes, there
could be two faces with different names yet identical meaning.
In that case, yes, the duplication could be eliminated.)
(There is an orthogonal reason to avoid using too many faces
at the same time: performance. But that is a different story
altogether.)
T> It was good you pointed out that faces are not just about
T> colour. Sometimes, I think peopoe forget this and only focus
T> on the colour aspect. However, this is understandable as
T> colour is what distinguishes most faces from each other.
T>
T> We need to acknowledge how difficult it is to define good
T> default faces. Many definitions fail to do this. While your
T> suggestion of using colour compliments can help, I'm not
T> convinced it is always that easy. One problem is that
T> different environments have different sets of colours to work
T> with. For example, if you work under the linux console, you
T> don't have compliments for most of the colours available under
T> other environments, such as X or (I presume) Windows/Mac. The
T> problem is further complicated because most developers won't
T> have access to many of these environments, so can't easil test
T> and design appropriate faces even if motivated to do so.
Agree. I did not mean to raise complementing as any kind of
cure-all - far from it. I was just mentioning that I provided
a quick-and-dirty set of default settings for dark backgrounds
for a particular library by flipping the light-background
defaults to their complements. Obviously, any set of defaults
for either light or dark deserves to be well thought out. And
all of the considerations you mention should be taken into
account.
The tty thing is a big limitation, in particular. Designing a
set of faces for use on tty only is a different task from
designing a set for use with many colors and other attributes.
For a library that is intended to work with both tty and
graphic windows, either tradeoffs are called for or
essentially two modes or face schemes are needed: full and
degraded (tty). We have constructs like `(type tty pc)' that
can help with that.
The tty face values are a little tricky because you have a much smaller set of attributes to work with and the attributes you do have have less options. However, the defface macro has the ability to handle this and while it may be a pain to do, it is doable and should be part of any fully defined face definition. I would suggest there are very few packages which are only designed to run within a GUI environment (e.g. doc-view I guess, can't think of many others).
T> I would not argue that inheritance is an ideal solution to
T> this problem, However, I do think it can be part of the
T> solution. Perhaps something along the lines of
T>
T> * Establish guidelines on how to use inheritance i.e. how to
T> select which face to inherit from
T> * Define a good (not too large) set of base faces. Existing
T> font-lock faces may be sufficient, maybe not. Would need
T> review.
T> * Require all face definitions in core emacs packages to
T> either fully define a face (i.e. definition for dark/light,
T> tty, X mac ms etc) OR inherit from a base face (assuming
T> all base faces are fully defined)
T> * Add a section to the manual encouraging developers to
T> either provide a fully defined face or inherit from a base
T> face, but don't just define a single (usually) light
T> background face
T>
T> The key here is that all faces in core emacs packages would
T> end up with a fully defined face, either explicitly or via
T> inherit.
Fully-defined, yes - good. The part that I think can be
misguided is basing everything on inheritance from faces that
are not necessarily related in terms of use or meaning.
Nobody has suggested basing everything on inheritance and it has not been suggested that inheritance should be forced on anyone (though, as outlined above, there could be a strong argument for forcing inheritance for clearly semantically related faces). The suggestion is that if you don't want to fully define a face, then use inheritance RATHER than a partially defined face.
Basing a face on a related face is not bad. Stretching things
to base all faces on some "basic" faces, no matter how
unrelated in terms of meaning or context, is not a great idea.
Nobody has suggested basing *all* faces on some base set.
Faces, including "basic" faces, are customizable. You don't
want a user who customizes `font-lock-doc-face' to suddenly
find that s?he has also affected a chain of unrelated faces
that inherit from it. Customizing font-lock faces should not
affect Dired or Info or...
Except they already do! I don't see this as a 'real' problem, but more a theoretical one. Yes, changing face attributes in font-lock-* faces will change the look of dired faces, but does that really matter in practice? Maybe the dired faces should be fully defined and I would not have an issue with that. However, I'm glad they are using inheritance rather than only having partial definitions.
.
T> One of the reasons I like the use of inherit for face
T> definitions is mainly from an end user perspective. I would
T> rather have faces that are fully defined via inherit, even if
T> that inheritance seems odd, than have a partially defined face
T> which only works if you have a light background or are running
T> under a full gui environment.
Those are not the only two alternatives - it's not either-or.
I am in favor of full face definitions. And I am not against
inheritance. The important thing is for a face to inherit
only from a related face (in terms of use/meaning).
I would argue it is preferable rather than being required.
The key is whether it will generally make sense for the
inheriting face if the inherited face gets customized. If
not, then inheritance is likely not the best way to go.
I actually agree, except we would differ on what makes sense.
T> If, when I change the base face definition, it results in
T> unacceptable changes to some face which inherits from it, I
T> can customize it.
Sure you can, but now you're back to customizing all over the
place - and now across multiple libraries and multiple use
contexts, to boot. The cure is at least as bad as the
disease.
No, its not as bad. If more faces inherited from fully defined core faces, then the faces I need to customize are only those which I find aesthetically unacceptable and does not include faces that are not fully defined and therefore are not even readable in my environment. Moreover, many of the faces I find aesthetically unacceptable are likely to have the same/similar attributes. I can change the base definition and have my changes propogate through all faces that currently have the unacceptable default. Without the use of inheritance, I have multiple faces to change. When they are not fully defined, many of those changes are needed just to make the face readable i.e. not just an aesthetic change, but a necessary one.
Nothing wrong with inheritance. But boiling everything down
to font-lock faces (or similar) is a bad idea. Better for
face inheritance to reflect face usage/meaning: families
(inheritance hierarchies) of related faces, not just
everything inheriting from primordial faces `adam' and `eve'.
Why do you keep taking the extreme? Nobody has suggested that all faces inherit form some low base. This is not what I've suggested - either fully define or inherit, just don't have partial poorly defined faces that only work in a limited environment, such as a light background.
T> My experience has been that this does sometimes happen, but
T> not that often and it is more preferable to fix up the few
T> faces than to spend much more time configuring lots of
T> individual faces.
I think you are again thinking of the fact that you are
needing to configure lots of faces because they were defined
incompletely or with poor defaults. Take away that
presupposition and where is the argument?
To take away that presupposition, you need to come up with something that enables developers to do the right thing and not only use partial face definitions as the default. This is the whole point. Yes, theoretically, if all faces were fully defined, most of the problem would go away (though there are then other issues concerning consistency). The reality is that too often, faces are not fully defined. Inheritance would provide a simple way to have a fully defined face when the developer cannot or does not want to fully define the face themselves.
T> In fact, as the number of individual face definitions has
T> increased, I actaully think we have gone the wrong direction.
T> We have too many faces which are mostly the same.
They are not the same just because they have the same
_appearance_ (by _default_ no less). This is a key element in
the confusion, I think. It sounds like it motivated Yidong's
search for faces to eliminate "duplication" via inheritance.
I acknowledge that. However, we have instances of faces that do represent the same semantic object, but which have different definitions in different modes i.e. clickable buttons etc. I have three different faces for representing dates (admittedly, these are add-on packages and not core ones), I have different faces for representing links etc. None of these use inheritance and in some cases, have different default values. In these instances, inheritance should be used. I then have the ability to set all like things to the same appearance and if I want, the option to change or augement them per mode.
Faces are not the same as their (attribute) values. Faces
have identity and purpose as well as values.
Agreed. We may differ on how far that identity reaches. I see dired-directory as having its own identity and its relevance is restricted to within dired mode. It inherits from a font-lock face, but I don't see that as part of its identity as such. You appear to see the face it inherits from as part of its identity as well. I'm not sure this is always so or necessary.
This is essentially no different from having multiple user
options (or other variables) that have the same value: 42,
nil, t,... You would not argue that we define a set of
"basic" user options and use inheritance to factor out any
"duplicate" options that have the same default value of 42 or
nil, would you?
You would not argue that we should have only one primeval user
option with a default value of 42, and inherit from it for
wildly different options with different use cases (meanings),
so that someone who customizes the "basic" option to change
the value 42 to 24 ends up changing lots and lots of
inheriting options. Would you? How are faces different in
this regard?
Now this is just plain silly and a very poor analogy . Faces have a lot more in common and a much closer relationship than al the user variables. Faces work together to present a theme, they are not independent as you imply. Faces that don't set an attribute inherit the value from the default face. You configure faces based on an overall theme and how they interact with each other and faces all have the same format/attributes. To suggest they are as indpendent from each other as other user variables is nonsense.
Ignoring how poor the analogy is, the fact is that NOBODY has suggested that all faces need to inherit form a base set. This was never proposed.
T> It seems now that every new package is adding its own face
T> definitions
Good. That should probably happen more than it does. ;-)
If reasonable, related faces exist on which to base the new
face definitions, then by all means inheritance might well be
called for. But a new package should _not_ avoid adding its
own face definitions, whether they are defined using
inheritance or not (i.e., pointer or copy).
Disagree. A package should only define its own face when either there is no existing face which adequately represents the meaining of the face OR there is a strong expectation that the user may want to customize the face independently. There is a definite danger of having too many faces and ending up with a consistency problem. Consider the situation where every programming mode defined its own face to represent comments and did not use inheritance. What benefit does that give us? Very little. What harm - potentially a lot as now you have to configure multiple faces to just get code comments to have a consistent appearance.
A mode should NOT create a new face just for the sake of it and if it does create a new face, either fully define the face or inherit from a fully defined face - its that simple. If you want to restrict inheritance to only use faces with the same semantic meaning, fine. I think it is over restrictive, but care less about that than about having a solution that would ensure faces are fully defined and providing a way to achieve this that will facilitate developers doing the right thing.
On the contrary. What should be avoided is reusing some face
that makes no sense in the current context. What is the
_practical_ criterion? Whether or not customizing the face
wrt its original context/purpose will have a negative effect
in the new context. If not, then go for it (reuse/inherit).
Agreed - pretty much my position.
T> and many of them are poorly defined. It now takes much
T> longer for me to establish a consistent set of faces.
Bad - agreed. But not a necessary consequence of having many
faces. More likely a consequence of poor default definitions
(as you mentioned).
Yes, but encouraging the addition of new faces without good justification is bad - it is the other extreme. Too often, I use applications that don't have enough faces and I cannot change the appearance of some object that I would like to somehow stand-out. However, the other extreme is a proliferation of unnecessary faces that just make customization and theming more difficult.
T> If we required face definitions to either be fully defined or
T> inherited from a base set that are fully defined, we would
T> likely give a much better default experience to end users.
Full face definitions are good, yes.
That is independent of the question of inheritance.
Well... indiscrimately imposing inheritance (from fully defined
faces) can ensure full definitions. But it has a cost: it can
also introduce unnecessary and unwanted dependencies with
negative consequences.
Well, either direction has a cost. There is no avoiding that. My view is to find the point at which we get the best cost/benefit. Inheritance provides a way to reduce the burden on developers to fullly define faces and has the potential to reduce the number of faces that are only partially defined and work only in limited configurations/environments. Whether we have strict or less rigid restrictions on inheritance will affect how easily inheritance can be used in this manner. Strict inheritance will give a consistent semantic meaning in inheritance chains and potentially more predictable resutls when modifying base faces. Less rigid inheritance would allow inheritance to be used instead of fully face definitions in more situations. If badly applied it does have the potential to cause confusion, but this could be mitigated with good guidelines. New faces should only be introduced when there is a demonstrated case and not just as an automatic default action.
T> Using inheritance also means that when we find a face
T> definition which is poor for a particular environment, we can
T> refine that base definition rather than having to find all
T> similarly poor definitions and updating them individually.
Yes and no. "Fixing" it for one environment might do exactly
the wrong thing for another context, e.g. for one of its
descendents. Inheritance needs to be used carefully, based on
intended use/meaning of the faces involved.
Maybe, though I don't think it is as bad in practice as you assume. Existing modes have been using inheritance in a non-semantic fashion since at least emacs 21 and this doesn't seem to have cause any major issues.
T> Using inheritance means that it is easier to make broad
T> changes to face definitions, reducing the time spent in
T> customize and lets you then tweak those specific faces which
T> don't quite work.
T>
T> So, using your example, if someone changed the base face that
T> dired+ uses, either they will find the result in dired+
T> acceptable or they can then tweak that face further. The
T> alternative is that it would be necessary to customize both
T> faces, even when you are going to set them to the same value.
Maybe, maybe not. Depends what kind of change you want/need.
It's true that if you want to change all occurrences of red
foreground to blue then more customization would be involved
without inheritance. Maybe we could find a way to make such
changes easier - I don't have a problem with that.
Maybe this could be an alternative. Frequently, you do need to change colours 'across the board' - often because the faces are not fully defined and you have a different background to the assumed default and need to make the change to make the face more readable. So, perhaps this would fix the symptom. However, it does not address the basic problem, which is faces that are not fully defined.
But we should not be using _inheritance_ for that (in
general). A Dired face should either not inherit or it should
inherit from a related face, not just some face whose _default
appearance_ looks good for Dired. It makes no sense to base a
Dired face on a font-lock face, for instance.
So you would argue that the existing dired face definitions are wrong. However, they ahve been like that for quite some time and it appears to work.
Just because you might want some Dired face to have a red
foreground by default is no reason to go looking for a face
with a red foreground to inherit from. Look instead for a
face with a related use/meaning. If you find none, then do
not use inheritance here. That's the guideline I'd suggest.
I emphasize the use/meaning of a given face: what it is for,
what it represents, what it does. I think you are emphasizing
its default appearance - attribute values (color etc.). To
me, a face or a variable `foo' is mainly about its use, not
its value.
No, I'm not focused on its appearance. The difference is that while I agree you should select the face that has a similar semantic meaning if one exists, I have no issue with using one that does not provided it does not cause confusion within the mode it is used in. I would cite dired as an example where this has been done successfully.
If the opposite were true, then we would name faces and
variables after their default values, not after their uses.
Yes, I've seen some Lisp code with face names like
`underlined-bold-red-foreground-on-gray-background'.
(Mea culpa: I even wrote such code at one point.)
And there's not necessarily anything wrong with that; for some
contexts it might make sense. But in that case it makes more
sense for the "face" to be a constant, not customizable. It
would be perverse to customize a face named `red-foreground'
to have a green foreground.
(And in general it is more likely for single attributes to be
reuse candidates than it is for combinations of attributes.)
T> The reality is that there are a limited set of good faces and
T> you will usually end up with the same face definition being
T> used in multiple roles. Frequently, those roles have nothing
T> to do with each other. This doesn't matter as the contexts
T> are completely different. From an end user perspective, it is
T> irrelevant that compiler messages inherit from
T> font-lock-string - all the end user sees is that compiler
T> messages use a default face that is green, which may be
T> exactly the same as strings in their code, but so what.
I strongly disagree here.
If the roles/meanings/use are unrelated, then inheritance is
usually inappropriate. It _does_ matter whether a
compiler-messages face inherits from `font-lock-string-face' -
_if_ someone customizes that parent face.
But does it really matter. I change font-lock-comment-face to orange because that is easier to read or more aesthetic given my default background colour. As a result, compiler-message face also changes to orange. Isn't it just as likely that if pink was not acceptable for comments in code that pink is also unacceptable for messages in compile-mode? Sure, maybe I might decide I'd still like pink for those messages and I can override the inheritance, but in practice, I think in most cases, this would be fine and has been my experience with the mdoes that do use inheritance in such a manner.
Of course, if there is a base face with a more closely fitting semantic meaning, it should be used in preference and you would avoid using faces like link or button that have very precise meanings that could cause confusion within the mode - especially if that mode supports links or buttons.
If we defined a compiler-messages face to inherit from
`font-lock-string-face' _only_ because we liked the default
foreground choice of `LightSalmon', that would be misguided,
IMO.
Perhaps, if that was the only motivation. However, if you choose that font-lock face because you want to use inheritance rather than spend time fully defining compiler-message face and if the font-lock face is fully defined, then it may be a valid choice.
If there is no existing face that is related in terms of
use/meaning, then the compiler-messages face should not
inherit; it should just be defined with a default foreground
of `LightSalmon'. That kind of duplication is not a curse but
a blessing.
NO, That would be a partial font definition. If I happen to use a background of LightSalmon, that face is now unreadable. Either fully define the face or inherit.
Then a user can customize either the compiler-messages face or
`font-lock-string-face' without affecting the other. And that
makes sense because (by hypothesis) the two are unrelated.