[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Native line numbers, final testing

From: Eli Zaretskii
Subject: Re: Native line numbers, final testing
Date: Wed, 26 Jul 2017 17:42:20 +0300

> From: Alex <address@hidden>
> Cc: address@hidden
> Date: Tue, 25 Jul 2017 21:50:59 -0600
> Hopefully the fixed-pitch issue is behind us now.

Seems so.

> > 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.

> > 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?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]