Re: Native line numbers, final testing

[Eli Zaretskii]

> From: Alex <address@hidden>
> Cc: address@hidden,  address@hidden
> Date: Wed, 12 Jul 2017 22:11:12 -0600
> 
> >> I don't see a single reason to make it different.
> >
> > It's for when the default face uses a variable-pitch font, as I
> > believe I already explained.
> 
> I wasn't referring to the fixed-pitch part, just the serif part. The
> addition of serifs is orthogonal to fixing the case of a
> variable-pitched default font. In your patch, you injected an unrelated
> property into the face that has nothing to do with fixing the
> variable-pitch issue.

I tried using fixed-pitch first, and it on my system it picked up a
bad font, that's why I switched to fixed-pitch-serif.  We should now
see if that gives satisfactory results, before using something more
elaborate, like different definitions for different platforms.

> Just to make myself extra clear: I am in favour of forcing line numbers
> to be fixed-pitch by default. However, I'm not in favour of using
> "Monospace Serif" instead of "Monospace" considering that the default is
> the latter.

But "Monospace" is not guaranteed to yield the same font as the
default face has in "emacs -Q".  It perhaps does that on your system,
but not on mine, and I don't expect it to do that for everyone.  The
"standard" font used by the default face in "emacs -Q" is determined
by the standard fontset, whose spec is window-system specific.
Moreover, "Monospace" etc. specifies a family, not a specific font;
what font will that produce depends on the OS (see comments to
face-font-family-alternatives) and on the fonts installed on the
particular user's system.

So if your expectation is that the line-number face by default uses
the same font as the one picked up via the standard fontset, it will
not be achieved by using fixed-pitch, except by sheer luck.

IOW, this is a complex issue, because the specific font used for the
face depends on factors some of which are OS-dependent and others
depend on the installed fonts.  At least some of these factors are
unpredictable, so choosing a good default that will work for everyone
is not easy.

The solution we seek needs IMO to satisfy the following requirements:

 . it should always use a fixed-pitch font, even if the default face
   or the standard fontset are customized to use a variable-pitch font
 . it should obey text-scale-adjust
 . it should be defined by defface, so it's easily customizable
 . it should yield the same visual appearance on all frames (unless
   the user explicitly customizes it differently for different frames)
 . it shouldn't change during an Emacs session, except if the user
   explicitly customizes it during that session

If you can come up with a way to satisfy these requirements while
producing the same font as the default face in "emacs -Q", please show
your solution.  I couldn't think of a way of doing that for all the
supported platforms, but I don't consider myself an expert on faces.
In any case, using fixed-pitch does NOT guarantee the same font as you
get by default, not on all platforms anyway, so doing that is not the
solution we seek.

It's possible that fixed-pitch-serif will produce unsatisfactory
results on some systems.  ("Unsatisfactory" here means that the
numbers look ugly or not easily legible, or we pick up a font of low
quality, like some raster font.  "Unsatisfactory" does NOT necessarily
mean identical to the default font in "emacs -Q".)  In that case, we
will have to look for better solutions.  But we are not there yet, IMO.

> I find it disappointing that you ignored the rest of my email.

I didn't ignore it, I just didn't see any constructive responses that
would advance the discussion.  All I see is a fundamental disagreement
where you repeatedly insist on getting the same font as in the default
case, which I think is a relatively weak requirement, and I don't know
how to achieve that universally without violating the stronger
requirements listed above.  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.

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

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