Re: Native line numbers, final testing

[Eli Zaretskii]

> From: Alex <address@hidden>
> Cc: address@hidden
> Date: Sat, 29 Jul 2017 00:12:42 -0600
> 
> >> That makes sense, but I still don't understand why explicitly inheriting
> >> from default makes a difference for face remapping. Is it just a
> >> hardcoded workaround?
> >
> > The inheriting face references its parent, so when the parent is
> > remapped, that affects the inheriting face through the attributes that
> > are inherited.
> >
> > What is "hardcoded" here is that text-scale-adjust affects the
> > 'default' face, so faces unrelated to it will not be affected.
> 
> Right, but it's not clear to me why explicitly inheriting from default
> is treated differently from an :inherit value of 'unspecified. From the
> manual:
> 
>   An ‘unspecified’ attribute tells Emacs to refer instead to a parent
>   face

That doesn't cover inheriting from 'unspecified'.  And it really
cannot cover it, because what is a "parent" face when the attribute is
':inherit'?

A comment in xfaces.c:merge_face_vectors says it all:

  static void
  merge_face_vectors (struct frame *f, Lisp_Object *from, Lisp_Object *to,
                      struct named_merge_point *named_merge_points)
  {
    int i;
    Lisp_Object font = Qnil;

    /* If FROM inherits from some other faces, merge their attributes into
       TO before merging FROM's direct attributes.  Note that an :inherit
       attribute of `unspecified' is the same as one of nil; we never
       merge :inherit attributes, so nil is more correct, but lots of
       other code uses `unspecified' as a generic value for face attributes. */

I've now added this caveat to the manual.

> I don't think the ability to customize it should go away, but the system
> in place that allows for the customization just seems odd to me.

IMO it isn't odd, it just didn't mean to affect any face but
'default' or its direct descendants.

> Instead of using an ostensibly redundant :inherit value, why not
> make a customizable list of faces that face remapping also affects?
> 
> Perhaps it's too much work for too little gain.

At this point, it certainly looks like that.