Re: Eliminating a couple of independent face definitions

[Tim Cross <theophilusx@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3245 bytes --]

On Tue, Feb 8, 2011 at 1:09 AM, Drew Adams <drew.adams@oracle.com> 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

[-- Attachment #2: Type: text/html, Size: 3742 bytes --]