On Tue, Feb 8, 2011 at 1:09 AM, Drew Adams
<address@hidden> wrote:
T> Ignoring implementation issues, your suggestion appears to
T> meet the main objective i.e. making it easier for programmers
T> to do the right thing and have fully defined faces without
T> having to jump through all the hoops. I would agree that it is
T> a better solution than using inheritance with semantically
T> unrelated parents as it does appear to provide a solution that
T> does not compromise the strict form of preferred inheritance
T> and a way to improve the quality of default face values.
T>
T> I would suggest that in addition to such enhancements to defface,
T> we need to provide guidelines in the manual on how to use
T> inheritance and copy and would go further and argue that for
T> semantically related faces, inheritance *should* be used to help
T> enhance consistency and allow users to customize a semantic
T> 'class' in one go.
Yes to guidelines in the manual and yes to encouraging inheritance among faces
with similar meaning/use. As I said:
d> We would encourage programmers to use `:inherit' when the
d> new face (its use/meaning/purpose) is related to the
d> referenced face - that is, when they want a change in the
d> latter to be reflected in the former.
d> We would encourage them to use `:copy-default' when the
d> referenced face is unrelated and all they want to do is
d> reuse its default-attributes spec.
We would encourage them to use one or the other, to get full face definitions
able to handle different backgrounds etc. And we would explain when it can be
good to use one vs the other.
We would also say why full definitions are important, and perhaps use an example
to point out characteristics of a full definition.
There is an example in the maual that shows using the different classes to handle tty, dark/light etc. Of course, this doesn't mean it couldn't be extended/improved.
I do see some possible implementation issues with the copy concept though. One problem could be determining when to do the copy. If I have face x and then define face y using your proposed copy semantics, how would you control when that copy occurs. For example, if I customize face x, how will face y know the next time emacs is started to use the old values of face x and not the new customized values? Somehow the defface would need to know to only copy the values from face x the first time it is defined/used i.e. from the first session that the face is used and to then keep those values for future sessions. Without this, you would simply have a form of delayed inheritance, which is likely going to be even more confusing that using normal inheritance as the change would be session dependent and time delayed. This seems like a non-trivial modification to the defface mechanism as it introduces a new state/time dimension i.e. copy face x attributes unless face y attributes have already been copied in a previous session. Maybe defface could have some type of 'initform' exstension that is used to configure the face if it has no custom setting. The result would need to be written to the custom-faces section so that it is only run once.
Tim