Re: Incorrect font weight selected

[Yuri D'Elia <wavexx@thregr.org>]

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.

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

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.

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.

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.

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.