From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.help Subject: Re: Emacs 28: Specific TTF font gets loaded with font-backend x instead of ftcrhb Date: Fri, 07 Feb 2020 11:48:34 +0200 Message-ID: <835zgig231.fsf@gnu.org> References: <87pneu1u9e.fsf@gnu.org> <83mu9ygyi7.fsf@gnu.org> <87imkmi46d.fsf@gnu.org> <83eevagoh8.fsf@gnu.org> <878slh0yr8.fsf@gnu.org> <83y2thezjq.fsf@gnu.org> <87v9okyyt5.fsf@gnu.org> <83pnerfuq1.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="59032"; mail-complaints-to="usenet@ciao.gmane.io" To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Fri Feb 07 10:49:22 2020 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1j00GI-000FHI-5Z for geh-help-gnu-emacs@m.gmane-mx.org; Fri, 07 Feb 2020 10:49:22 +0100 Original-Received: from localhost ([::1]:53030 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j00GH-0001rR-6Z for geh-help-gnu-emacs@m.gmane-mx.org; Fri, 07 Feb 2020 04:49:21 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38848) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j00Ft-0001n6-Fn for help-gnu-emacs@gnu.org; Fri, 07 Feb 2020 04:48:59 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:36821) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1j00Ft-0001I6-Bo for help-gnu-emacs@gnu.org; Fri, 07 Feb 2020 04:48:57 -0500 Original-Received: from [176.228.60.248] (port=3593 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1j00Fr-0000i5-T8 for help-gnu-emacs@gnu.org; Fri, 07 Feb 2020 04:48:56 -0500 In-reply-to: (message from Tassilo Horn on Fri, 07 Feb 2020 09:57:36 +0100) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.io gmane.emacs.help:122364 Archived-At: > From: Tassilo Horn > 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).