RE: Eliminating a couple of independent face definitions

["Davis Herring" <herring@lanl.gov>]

>> Having D copy from B is equivalent to having them both
>> inherit from a new face A with B's previous definition.
>
> It is certainly not equivalent.
> Just customize A to see the difference.

But A didn't exist before, so that's a new feature, not a difference per
se.  If we wanted, we could prevent the user from even knowing about A
(have `customize-face' not support it), and they would be equivalent.  So
surely this is better...?

>> With the inheritance, the user does have the option
>> to change both of them at once if desired.
>
> Precisely why they are not equivalent.  Read the thread, if you have not
> already, for why inheritance is not the be-all and end-all.

I'm quite surprised that you didn't leap at this idea.  Since when is
offering the user a choice a bad thing?  If they don't want to customize
A, they won't, and they'll then have exactly the same set of options that
the copying idea would give them.

Now, I must say that I've realized an imperfection in my idea: if Emacs
defines D but not B (and thus no one bothers to make A), an external
package that defines B must either inherit from D or copy-paste its
definition.  But faces in Emacs that seem worthy of inheritance by anyone
may be mechanically transformed into D-A pairs to avoid the problem.

>> And we already have inheritance.
>
> Hammer...nail.

David J. Wheeler might disagree.  (And you were talking about how it might
be non-trivial to implement the copying idea.)

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.