Re: Incorrect font weight selected

[Eli Zaretskii]

> From: Yuri D'Elia <wavexx@thregr.org>
> Cc: dgutov@yandex.ru, monnier@iro.umontreal.ca, larsi@gnus.org,
>  emacs-devel@gnu.org
> Date: Wed, 05 Jan 2022 18:11:50 +0100
> 
> On Wed, Jan 05 2022, Eli Zaretskii wrote:
> > Thanks, but this is a scary change.  I have no idea what unintended
> > consequences it could cause.
> 
> At least on X11, I've tried creating frames both normally, using the
> daemon (across x11 and terminal sessions), and generally I've been using
> this for about a week.

I believe you.  But the problem is that there are so many different
use patterns with fonts and faces that it is impossible to test all
the consequences in such a short time, certainly by a single
individual.

> > Can we back up a bit, and understand how the change in 1b2511f
> > triggered the problems you see?  If you already understand that, can
> > you describe it?  Maybe we could then come up with a safer, better
> > understood change.  If nothing better comes to mind, I'd prefer to
> > revert 1b2511f than doing something like what you propose.
> 
> Overall, the change in 1b2511f seems correct to me. font_list_entities
> (and the downstream font_delete_unmatched as touched by 1b2511f) can
> return a list of candidates which can be used subsequently for
> refinement.
> 
> If you look at the main font_find_for_lface which is where the action
> takes place, this is done by using font_list_entities first, then using
> font_select_entity to narrow it down further. This works as intended
> already, and that's why the problem only showed itself on new frames
> and/or with the daemon (which doesn't immediately create a frame).

Then maybe I didn't realize what problem are you trying to solve.
Does the problem happen only with new frames?  At least Sean Whitton
said in this thread that his problems caused by 1b2511f are not with
new frames, AFAIU.

Could you please describe again the problem you are debugging?

> When creating a new frame though, the attributes do not come from the
> existing face spec the user supplied, but are are reconstructed from the
> full font name that matched in the first frame instead.

But that sounds like TRT to me, at least in general, because an
existing frame could have all kinds of frame parameters that don't
necessarily apply to new frames.

> I wrote above my guess about why this seems to be done in this way. We
> could probably do better by re-using the attributes in the frame that
> called make-frame (if that frame is of the same type as the new frame),
> but that requires a bit more work.

I don't think this would be correct, since frames are supposed to be
independent wrt faces.

> So in the end we're left with font_open_by_name, which is passed a fully
> qualified font pattern/name, parses it, but then resets the attributes
> for selection, discarding the font attributes as set by the user. It
> used to work as the returned entities only matched the requested font
> exactly, so no selection ever took place.

Ah, so this is where 1b2511f comes into the play...

In any case, if 1b2511f causes other problems, then reverting it would
solve those problems and this one as well.  We are then left with the
problem reported by Dmitry.

> The original commit introducing font_open_by_name also has the attribute
> override, so that commit doesn't really tell me much about it. Maybe
> font_list_entities never returned multiple weights/slants as we're doing
> now, so the problem went unnoticed for a long time.
> 
> Or something else I don't see in the other font backends. Still, I do
> support the change in 1b2511f despite the breakage. I'd rather fight
> with the breakage introduced by this change.

The problem is we are fighting blind, without real understanding of
the overall logic and the implementation details of this part of
Emacs.  And users are extremely annoyed when their beloved font
suddenly fails to be selected.  I'd rather avoid the waste of time and
energy on this kind of problems.  At least until someone comes aboard
who will know enough about this part to fix any problems quickly and
efficiently.

And I'm still not sure your change is correct in principle, as it
makes faces on frame N depend on faces on some frame N-m, which was
the selected one when frame N was created.  That doesn't sound right
to me: each new frame should start from the same default starting
point.  I'd even go as far as repeating in the new frame the same
steps of selecting the font that were done initially, without any
shortcuts, so that we won't need anything from the previous frame(s).