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>
> Cc: help-gnu-emacs@gnu.org
> Date: Sat, 08 Feb 2020 13:29:47 +0100
> 
> >> We should not signal this error when the unibyte string is
> >> pure-ASCII.  Let me think of a solution.
> >
> > Does the below help?
> 
> Yes, it does help.  The error is gone.

Thanks, I installed it on master, since even though such compositions
are undesirable, they are better then an infinite sequence of errors
during redisplay.

> > If it does, you should see the "--" in the mode line replaced with the
> > ligature (whether this is the desired behavior is another question).
> 
> Exactly, and here I'd say it is definitively not the right behavior
> because because both chars have a separate meaning (buffer writable?
> and buffer modified?) and help-echo which aren't accessible anymore.
> 
> I don't know how to cope with such situations.

We could insert a ZWNJ character between the two characters, but that
is not a general solution, since mode-line strings can be dynamically
consed by applications, and at least the input-method indicator on the
mode line must be able to display composed characters.  I guess this
is something else we should figure out before we can freely use
ligatures in Emacs.

> Maybe composition should only consider strings with equal text
> properties.

That already happens, at least with face properties.

> Or, as you already said, there should be some text property
> inhibiting composition which the mode-line could use.

Yes, maybe.  Although that, too, could have problems with mode-line
strings produced by Lisp programs.