Re: Native line numbers, final testing

[Alex]

Eli Zaretskii <address@hidden> writes:

>> From: Alex <address@hidden>
>> Cc: address@hidden,  address@hidden
>> Date: Wed, 12 Jul 2017 14:03:15 -0600
>> 
>> Eli Zaretskii <address@hidden> writes:
>> 
>> >> From: Alex <address@hidden>
>> >> Cc: address@hidden,  address@hidden
>> >> Date: Wed, 12 Jul 2017 11:22:51 -0600
>> >> 
>> >> > It should be sensible, I agree.  But "sensible" doesn't necessarily
>> >> > mean identical to the default face's font.
>> >> 
>> >> Sure, but I maintain in this case that it does mean identical to the
>> >> default face's font.
>> >
>> > I don't understand why, and I don't think I agree.
>> 
>> 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.

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.

> And instead of repeating the same arguments again and again, I think
> we should simply agree to disagree, and wait for others to offer their
> opinions and experiences about this.

I don't see how the discussion was about to devolve into repetition
(though there appears to have been some miscommunication). While I agree
that others should give their input, I find it disappointing that you
ignored the rest of my email.

>> >> (insert (propertize "hello there!" 'face 'fixed-pitch))
>> >> 
>> >> This text increases along with the default face with "C-x +". Why does
>> >> the same not apply to the line-number face?
>> >
>> > I don't know.  Feel free to investigate and publish the findings.
>> 
>> Well, it definitely seems like a bug to me. text-scale-mode uses
>> face-remap-add-relative on 'default, but I don't see why this would
>> cause an issue. The manual states that any 'unspecified attributes mean
>> that the attributes are taken from the default face, so I don't see why
>> adding :inherit 'default should even make a difference.
>> 
>> Perhaps I should file a bug report?
>
> 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.

Just to be clear, this is what the manual states[1]:

   Apart from the values given below, each face attribute can have the
value ‘unspecified’.  This special value means that the face doesn’t
specify that attribute directly.  An ‘unspecified’ attribute tells Emacs
to refer instead to a parent face (see the description ‘:inherit’
attribute below); or, failing that, to an underlying face (*note
Displaying Faces::).  The ‘default’ face must specify all attributes.

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

Footnotes: 
[1]  (info "(elisp) Face Attributes")