Re: Emacs 28: Specific TTF font gets loaded with font-backend x instead of ftcrhb

[Eli Zaretskii <eliz@gnu.org>]

> From: Tassilo Horn <tsdh@gnu.org>
> Date: Fri, 07 Feb 2020 09:57:36 +0100
> 
> On Thu, 2020-02-06 at 20:15 +0200, Eli Zaretskii wrote:
> > > After evaling that, -> becomes an arrow and ~> becomes an arrow with
> > > curvy stroke.  So either there's some issue with PragmataPro or my
> > > computer at home.
> > 
> > Well, it would be interesting to hear what happens with that other
> > machine and/or the font.  Be sure to try that in an Emacs built with
> > the HarfBuzz library, as it should have the most advanced ligature
> > support there is.
> 
> I'm pretty sure I had built with HarfBuzz but tried again anyway.  This
> time it worked just fine.  I'll attach a screenshot showing two emacs
> frames with ligatures in action.  The left one is with the JetBrains
> Mono font, the right one is with the PragmataPro Liga font.

So the conclusion is that this works with both fonts?  (I cannot be
sure because the two displays look somewhat differently).

> > > Do I understand it correctly that "overshooting" with the above
> > > rules has no bad effect, i.e., if there is a composition rule for ->
> > > but the font has no ligature glyph for that, then it just stays the
> > > way it is?
> > 
> > Not exactly.  In Emacs built with HarfBuzz, you will see the original
> > ASCII characters displayed, but handled as a single grapheme cluster,
> > i.e. the cursor will be "widened" to include all of them, and a single
> > C-f will move across all of them.
> 
> That doesn't seem to happen.  forward-char moves inside ligature
> sequences no matter if the font has a ligature or not.  I.e., even with
> a ligature ~= which gets composed to an equal sign with curvy upper line
> point move half-by-half.

I think that's because you use font-shape-gstring directly.  You
should use compose-gstring-for-graphic instead.

> > > So there could be some ligature-minor-mode which just adds all
> > > possible composition rules?  (Just speaking naively, I guess there
> > > are several distinct categories of ligatures which you would want to
> > > enable/disable on a per-mode basis.)
> > 
> > The part in parentheses is exactly the non-trivial part: we should
> > figure out which ligatures should be in effect in what major modes,
> > and probably also as function of some user preferences (such as the
> > language used in the buffer).  IOW, we need to design the UI for
> > specifying what classes of ligatures to activate.
> 
> I've tried categorizing them a bit but this feels like quite a hard
> task, and I've just done programming ligatures.  Does -- fit in an
> operators category (because of C, Java, ...) or a comment category
> (because of SQL) or better forget about concrete language syntaxes and
> have a dashes category?

Yes, this is non-trivial.

> > Burt if you only care about ligatures in programming languages, the
> > job becomes much simpler, I think.  Although I'd still expect the
> > ligatures in effect to depend on the programming language of the
> > current buffer.
> 
> Right now I've just enabled anything.

Not really everything, IMO, as there are also ligatures relevant only
to human-readable text.  For example, see this URL:

  https://en.wikipedia.org/wiki/Orthographic_ligature#Ligatures_in_Unicode_(Latin_alphabets)

> To me it seems like there is some guideline like "if ligature X is
> not applicable in programming language Y then the characted sequence
> it is composed from won't appear there anyway".

This is probably correct for programming-language major modes, yes.

> But one thing which comes to mind is that one might want to suppress
> ligature composition inside strings...

Which probably means we'd need some text property to disable
composition there.

> > Which means composition-function-table needs to be buffer-local, and
> > we should make sure making it buffer-local does TRT.
> 
> This doesn't seem to work right now.  See the FIXME at the bottom of
> below code.

We need to fix that.  We do have buffer-local char-tables, for example
buffer-display-table.  We should probably define a buffer-local
composition-function-table in the same way, and have a global table as
its parent or something (for language-specific compositions, like
those for accented letters).