RE: Eliminating a couple of independent face definitions

["Drew Adams" <drew.adams@oracle.com>]

T> I do see some possible implementation issues with
T> the copy concept though. One problem could be
T> determining when to do the copy. If I have face x
T> and then define face y using your proposed copy
T> semantics, how would you control when that copy occurs.

I have not thought about implementation, nor will I really try to. ;-)  I leave
that to others more knowledgable.

I did say what I thought was called for wrt copy time, however: copy when the
`defface' with the `:copy-default' gets eval'd.  Normally, that's at load time.

And I did mention that only the default-attributes spec would be copied from the
reference face - not the current values of its attributes:

d> Why not introduce a new `defface' keyword `:copy-default'?
d> It would define the new face with the same default
d> attribute values as another face.  A copy of those values
d> (actually, of the attributes spec) would be made at
d> `defface' time.

d> Only the _default_ attribute values would be used; the
d> current values of the reference face would have no effect
d> at any time.

IOW, this is a relation between two face _definitions_ (two `defface's), not
between a `defface' and another face's current attribute values.

Yes, this would likely require saving the referenced face spec in some form in
the byte-compiled reference file, if that is not done already.  And it would
require copying that spec to the receiver at its `defface' eval time.

[Another possibility is to allow copying when the receiver `defface' is
byte-compiled, not just when it is eval'd.  Dunno whether that would be a good
idea or whether it could introduce differences (eval vs compile time).]

No, I haven't tried to think this through, and especially not in terms of
implementation.  Just throwing the idea out there as food for thought by others
more qualified.

T> For example, if I customize face x, how will face y
T> know the next time emacs is started to use the old
T> values of face x and not the new customized values?

See above.  It would always look to face x's _definition_ (`defface'), not to
its current attribute values.  Customization of face x should have no effect.

T> Somehow the defface would need to know to only copy
T> the values from face x the first time it is defined/used
T> i.e. from the first session that the face is used and
T> to then keep those values for future sessions.

Not sure I follow you.  It would _never_ copy the current values.  It would copy
only the attributes spec from the reference face, that is, the part of the
definition that is called for being copied.

But yes, that spec would need to be available, in the source reference file (no
problem) and in the byte-compiled reference file.  A copy chain could presumably
handled: if C copies from B which copies from A, then B's defface would be
eval'd before C's defface.

There might be some problems to work out, but I don't imagine they would be
insurmountable.  (But I know nothing about face implementation or
byte-compilation.)

T> Without this, you would simply have a form of delayed
T> inheritance, which is likely going to be even more
T> confusing that using normal inheritance as the change
T> would be session dependent and time delayed.

I don't follow.  Again, it is only the default-attributes spec that would be
copied, not the current attribute values.  Access to that spec is all that is
needed, I think.  And it should be possible to provide that access through the
byte-compiled reference file (as well as through the source reference file) -
that is, the file whose `defface' is copied from.

But again, I might well be missing a thing or two (or three...).

T> This seems like a non-trivial modification to the
T> defface mechanism as it introduces a new state/time
T> dimension i.e. copy face x attributes unless face y
T> attributes have already been copied in a previous session.

The current attribute values would never be copied.  Only the default-attributes
spec would be copied - that is, the part of the reference face's definition (its
`defface') that we specified to be copied.

T> Maybe defface could have some type of 'initform'
T> exstension that is used to configure the face if it
T> has no custom setting. The result would need to be
T> written to the custom-faces section so that it is
T> only run once. 

I don't follow.  But maybe you just misunderstood and thought I meant that the
current attribute values would be copied?