From: Tassilo Horn <tsdh@gnu.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: help-gnu-emacs@gnu.org
Subject: Re: Emacs 28: Specific TTF font gets loaded with font-backend x instead of ftcrhb
Date: Fri, 07 Feb 2020 11:41:57 +0100 [thread overview]
Message-ID: <87lfpe65my.fsf@gnu.org> (raw)
In-Reply-To: <835zgig231.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 07 Feb 2020 11:48:34 +0200")
[-- Attachment #1: Type: text/plain, Size: 3166 bytes --]
Eli Zaretskii <eliz@gnu.org> writes:
>> 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).
I'd say, yes. There are some slight differences in which ligatures
those two fonts support, of course.
>> > 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.
Ah, then it works as you've described. I actually like this behavior.
>> > 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)
Yes, right. I meant "all that I've listed" which are just those I could
copy & paste from the JetBrains Mono homepage and those are basically
just the typical programming ligatures.
>> 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.
Yes, something like that.
>> > 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).
Sounds about right.
By the way, if I enable ligatures, I get reproducible infloops or
something alike. The visual bell starts ringing/blinking, C-g won't
help, and even with debug-on-{error,quit} I'm unable to get into the
debugger. I can reproduce that simply by starting Gnus and trying to
enter a group but I got that also once with pushing my commits in Magit
and sometimes when quitting emacs with C-x C-c.
Attached is a GDB backtrace.
[-- Attachment #2: gdb.log.gz --]
[-- Type: application/gzip, Size: 3642 bytes --]
[-- Attachment #3: Type: text/plain, Size: 14 bytes --]
Bye,
Tassilo
next prev parent reply other threads:[~2020-02-07 10:41 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-04 11:12 Emacs 28: Specific TTF font gets loaded with font-backend x instead of ftcrhb Tassilo Horn
2020-02-04 12:15 ` Robert Pluim
2020-02-04 12:25 ` Robert Pluim
2020-02-04 12:58 ` Tassilo Horn
2020-02-04 13:54 ` Robert Pluim
2020-02-04 14:21 ` Tassilo Horn
2020-02-04 16:26 ` Robert Pluim
2020-02-04 18:32 ` Tassilo Horn
2020-02-04 20:11 ` Robert Pluim
2020-02-05 16:51 ` Tassilo Horn
2020-02-04 15:31 ` Eli Zaretskii
2020-02-04 18:43 ` Tassilo Horn
2020-02-04 19:08 ` Eli Zaretskii
2020-02-05 16:44 ` Tassilo Horn
2020-02-05 17:04 ` Eli Zaretskii
2020-02-06 7:12 ` Tassilo Horn
2020-02-06 18:15 ` Eli Zaretskii
2020-02-07 9:21 ` Tassilo Horn
[not found] ` <b271f1084b17a53ee1583d1f8cd92e9ed21cf360.camel@gnu.org>
2020-02-07 9:48 ` Eli Zaretskii
2020-02-07 10:41 ` Tassilo Horn [this message]
2020-02-07 13:28 ` Eli Zaretskii
2020-02-08 9:39 ` Tassilo Horn
2020-02-08 9:52 ` Tassilo Horn
2020-02-08 10:16 ` Eli Zaretskii
2020-02-08 10:36 ` Eli Zaretskii
2020-02-08 12:29 ` Tassilo Horn
2020-02-08 13:50 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87lfpe65my.fsf@gnu.org \
--to=tsdh@gnu.org \
--cc=eliz@gnu.org \
--cc=help-gnu-emacs@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).