Re: Native line numbers, final testing

[Alex]

Sorry for not replying sooner. Hopefully the fixed-pitch issue is behind
us now.

Eli Zaretskii <address@hidden> writes:

> Disagreements about defaults are
> frequently like that, they can only be resolved by collecting enough
> opinions and experiences; 2 opposite experiences are definitely not
> enough.

Fair enough.

>> > I don't think I understood what you consider a bug here.  Face
>> > attributes are calculated when the face is created, they are not
>> > updated whenever the default face changes.
>> 
>> Not in the case of 'unspecified, right? Evaluating (set-face-bold
>> 'default t) changes every face with an 'unspecified bold attribute to
>> bold.
>
> 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?

>> So if I'm understanding this correctly, then you shouldn't have to
>> inherit from 'default since any unspecified attributes already fallback
>> to 'default. The behaviour in this case is different, therefore this is
>> a bug (something isn't handling face-remapping-alist correctly).
>
> 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?