Re: Eliminating a couple of independent face definitions

[Tim Cross]

On Tue, Feb 8, 2011 at 9:12 AM, Drew Adams <address@hidden> wrote:

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?

Like you say, it probably needs to be looked at by someone with more knowledge. My thoughts were that since defface is a macro, we can only get at its specification at load time. However, can we get to that specification before emacs has loaded the custom faces section or user init files that would/could modify that specification?

If we can't, then I guess it would be necessary to somehow parse the original source or byte-codes, which begins to make the whole thing a lot more complex - I'm not even sure how you would identify the appropriate file that contains the defface spec. 

Complex doesn't mean it cannot be done, but it does mean it will be far less likely that anyone would want to implement it. If nobody is willing to implement it, then it all becomes academic and nothing happens. Thats why I think it is important to also consider implementation implications, even if we don't plan to actually do the implementation ourselves. At worst, it does no harm, at best, it might provide the seed for implementation or a better idea. I also suspect 'ideas' which don't attempt to examine implementation implications are unlikely to be taken vary seriously or gain any traction. 

I think its necessary to have a clear grasp of emacs' initialization process/order to really know what options there are to implement a 'copy' facility. I'm beginning to think that a better alternative would be to add a simple command for developers that would just, given a face name, put its current definition into the kill ring/register/buffer in a format appropriate for using in a defface definition. Essentially, this would be a convenience wrapper around find-face-definition that extracts the definition from the source file. This seems less complicated and may still provide an easy way for developers to copy an existing full face definition without having to manually locate the sources, cut and then paste. Could mean less reason to not provide a fully defined face definition. The disadvantage is that once set, it would not reflect any changes in the default definition of the face it is copied from, which would be the main advantage of your suggestion. However, I suspect the defface definitoin of most faces rarely changes, especially for some of the older base faces that have been around for a while and have probably already been tweaked to be as good as they can be.

Tim