Re: Native line numbers, final testing

[Alex]

Eli Zaretskii <address@hidden> writes:

>> From: Alex <address@hidden>
>> Cc: address@hidden
>> Date: Tue, 25 Jul 2017 21:50:59 -0600
>> 
>> > Yes, but face remapping is not implemented by setting attributes of
>> > existing faces.  It (internally) produces new faces and redirects
>> > existing faces to those new ones.  And I think there's a good reason
>> > for that: we definitely do NOT want _all_ the faces to change their
>> > sizes to follow the remapping of 'default'.  For starters, we only
>> > want the faces to change in the current buffer, and we don't want
>> > faces like 'tooltip' and 'mode-line' to change even for the current
>> > buffer.
>> 
>> 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

>> > face-remapping-alist is only handled where we decided to handle it,
>> > and I think I at least partially understand why, see above.
>> 
>> Would it make sense to handle it in the line-number area? 
>
> I don't know.  Why should it?  It didn't affect linum and nlinum
> faces.  What we have now allows users to customize the face both if
> they want it to be sensitive to scaling, and if they don't.  Why
> should we take that freedom from them?

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. 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. In that case, then at
least documenting the current behaviour would be nice.