Re: Buffer-local faces

[David Kastrup]

Miles Bader <address@hidden> writes:

> On Mon, May 03, 2004 at 06:42:10PM -0400, Stefan Monnier wrote:
> > >       (FACE NEW-FACE MERGE-FACE...),
> > >    which causes NEW-FACE to be used where FACE normally would.
> > >    If present, MERGE-FACE... are merged during display with NEW-FACE.
> > 
> > How often would you need MERGE-FACE(s) ?  I ask because it seems
> > unnecessary since you can also use a new face with a :inherit slot
> > instead, right?
> 
> My thought was that this would be convenient for people that want to
> just tweak faces in a mode-hook, and allow them to do it without
> making a new face.  It's annoying to always have to name everything.
> Implementation-wise I don't think there's any real cost to allowing
> it (the code to merge from a list of faces is already there for the
> use of :inherit).

I am uncomfortable about the whole change.  And the reason has to do
with the feature freeze.  Now you may argue that the change is not so
intrusive as to be likely to trigger new bugs, but that's beside the
point.

The first question to resolve with regard to a new feature is to
figure out how to do it right, not how to circumnavigate the feature
freeze best.  If we base a decision like this on criteria like a
feature freeze, then it may come back to haunt us at a later time.

So I think we should first try to resolve what the perceived problem
is, what extensions or generalizations of this problem should also be
solvable, and what would be the most logical, consistent and useful
way to tackle it.

_After_ we have made that decision, we can check if it is consistent
with the goal to put it in the next version, and have that version
appear at a reasonable date.  But basing the design on this criterion
in the first place seems dubious to me.

It just appears that a buffer-local replacement list is a kludge for
avoiding a more general scheme of context-dependent faces (probably
related to the XEmacs locale/specifier stuff), and maybe other things.

If the functionality appears very necessary for the release, one can
still decide about a higher level package writer level API for the
problem set to be tackled, and implement this API on top of a cheap
workaround for a single release, after carefully weighing the
benefits.  And then replace workaround and the implementation of the
API in the next release.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum