From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: =?UTF-8?Q?Cl=c3=a9ment_Pit-Claudel?= Newsgroups: gmane.emacs.devel Subject: Re: Ligatures (was: Unify the Platforms: Cairo+FreeType+Harfbuzz Everywhere (except TTY)) Date: Fri, 22 May 2020 09:26:05 -0400 Message-ID: <895400a0-a87a-70fe-b6ca-85c14c4745fa@gmail.com> References: <20200517165953.000044d2@web.de> <83lflqblp0.fsf@gnu.org> <83ftbybio3.fsf@gnu.org> <83zha69xs2.fsf@gnu.org> <83367x9qeq.fsf@gnu.org> <0ccae2a4-533b-d15c-2884-c2f00b067776@gmail.com> <83wo5987mk.fsf@gnu.org> <99d4beed-88ae-b5cd-3ecb-a44325c8a1dc@gmail.com> <20200518215908.GA57594@breton.holly.idiocy.org> <83mu6481v3.fsf@gnu.org> <75a90563-51b4-d3b8-4832-fc0e2542af0d@gmail.com> <83blmi7hys.fsf@gnu.org> <837dx55qff.fsf@gnu.org> <834ks95cmz.fsf@gnu.org> <4faa291f-f2df-36d1-73d5-332b93a9b6d8@gmail.com> <83y2pk2nzy.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="97798"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 Cc: alan@idiocy.org, pipcet@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri May 22 15:26:51 2020 Return-path: Envelope-to: ged-emacs-devel@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 1jc7hK-000PIV-0u for ged-emacs-devel@m.gmane-mx.org; Fri, 22 May 2020 15:26:50 +0200 Original-Received: from localhost ([::1]:47886 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jc7hJ-0007o7-3E for ged-emacs-devel@m.gmane-mx.org; Fri, 22 May 2020 09:26:49 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48900) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jc7gi-0006wY-Ml for emacs-devel@gnu.org; Fri, 22 May 2020 09:26:12 -0400 Original-Received: from mail-qk1-x72b.google.com ([2607:f8b0:4864:20::72b]:33326) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jc7gh-00069l-HF; Fri, 22 May 2020 09:26:12 -0400 Original-Received: by mail-qk1-x72b.google.com with SMTP id z80so10702664qka.0; Fri, 22 May 2020 06:26:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=tcRsAmd8TcjxBQlSZxTfeF2BKqVGdgQLLwWRceen3Bw=; b=Kc5Hpe7xF/DiqczU8H9WoZR7pCVBpPLzpLjkpzOBvTvbDfmGZbbHK6gReQPkK1RqlD Halslg0PfoA6JUHVOOogIWtVwtCvzBRB6ErS++rLFjQlzzV382aqyihzw59ZjJFHmxdI TM0V07hXRHZ/dWkGlQq/NQL+whxCli2b6iEBs6RCpLgZ9lCFpeP1yXRfZw2geCyWKKNS mfvzHNOgcf47N5FctPHt8Yt8eTM/8zkm48nwGoZSryDUlvfv6P0H/d7sErysOqbV2ZuQ tx4Ez7/WCCna82j9UqiR/IGoBBKDwdByAdQqVJBRBdBiMkgL/St27v7xRMcdOikikyCF 5ZfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=tcRsAmd8TcjxBQlSZxTfeF2BKqVGdgQLLwWRceen3Bw=; b=V+/k8X8kTOGIWdbsuI0CBOj5T5S5djZJ+YW5MctxDNJgu4tpU50n9aOX0kOHyRjSsr uQMEPxrXG/5TB3rv1DohsM/Wz1KvuBxoICIJml59oQ1h0mZIhYqRTtZsH2FN2j8R4fzW NlaE4hMakA714XAOe85VRrh/FvrvakNX6sY0rdP5y8x4/Z/ojRS53cDsGVXanO+ci71h pH7q0OJMfqphXvqs+V0j3rhuJ8wJ3HVv+2hzO2vrjHTKwgx3HQHwJIuFUWjwNvQKyP+O Mv8cM7++rpXY606mhIc75D+FKJcmo0eMSAoccnZYCY+uUNQVasDQY94MD8mi3ImvOA3A PHYw== X-Gm-Message-State: AOAM530jTvk8hTOAOeekm5DDp561Q56BNtva6LMVeVMRFjUrUw7TuT61 f25iI+zhS3x5usaq5ZQoLElYPTU9 X-Google-Smtp-Source: ABdhPJzJJNZFi8ufdwGLXM23fxb3O0qiv4i7kRkeOy1gwleQkFrvKOkrpxMEQNse3Au30f5Z8Lqh9Q== X-Received: by 2002:a05:620a:108e:: with SMTP id g14mr14635742qkk.337.1590153967591; Fri, 22 May 2020 06:26:07 -0700 (PDT) Original-Received: from ?IPv6:2601:184:4180:66e7:bda5:ac5c:1de0:b677? ([2601:184:4180:66e7:bda5:ac5c:1de0:b677]) by smtp.googlemail.com with ESMTPSA id h185sm5866011qkd.80.2020.05.22.06.26.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 22 May 2020 06:26:06 -0700 (PDT) In-Reply-To: <83y2pk2nzy.fsf@gnu.org> Content-Language: en-GB Received-SPF: pass client-ip=2607:f8b0:4864:20::72b; envelope-from=cpitclaudel@gmail.com; helo=mail-qk1-x72b.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:251225 Archived-At: On 22/05/2020 07.44, Eli Zaretskii wrote: >> Cc: alan@idiocy.org, emacs-devel@gnu.org >> From: Clément Pit-Claudel >> Date: Thu, 21 May 2020 16:51:47 -0400 >> >> On 21/05/2020 15.08, Eli Zaretskii wrote: >>> That would prevent Emacs from controlling what is and what isn't >>> composed, leaving the shaper in charge. We currently allow Lisp to >>> control that via composition-function-table, which provides a regexp >>> that text around a character must match in order for the matching >>> substring to be passed to the shaper. We never call the shaper unless >>> composition-function-table tells us to do so. >> >> Does this mean that for each font we need to re-encode the font's logic for deciding whether to use a ligature? > > I don't think so, but I'm not yet sure I understand all the details of > the use cases you have in mind. See also my responses to Pip Cet: > perhaps they answer also your questions here. > >> Some concrete examples: in Iosevka (*, (**, (***, (**** etc are all displayed with the * character vertically centered relative to the (, but a lone * is not centered. In Fira Code, punctuation is context-aware, so the "+" in "A + B" is not the same as the "+" in "a + b". In both of these faces, arrows can be of any length, and in Fira Code you can even mix and match them (see https://raw.githubusercontent.com/tonsky/FiraCode/master/extras/arrows.png). > > How do you solve this in prettify-symbols-mode? You don't, which is unfortunate. prettify-symbols-mode was extremely cool a few years ago when fonts with programming ligatures were mostly unheard of, and it's still extremely nice for things like prettifying lambda in λ, but for things like turning ascii arrows into pretty arrows it lags behind the more recent ligature stuff. > In general, I envision that people would use the font they find > acceptable for the ligatures they want/need in each mode or buffer > where they need that. If for some reason different fonts could > determine which ligatures you do NOT want to see, then I guess we will > have to provide some easy-to-use UI for that, which would manipulate > the relevant data structures under the hood. Alternatively each font > could require a separate composition function to go with it. It would be weird for Emacs to be the only program that requires re-encoding the entire ligature logic of each font it attempts to use. Different fonts offer different ligatures, and if I want to select a subset the font itself provides variants that let me do this. Meanwhile, I hope that we can make Emacs act like browsers or other editors in that if I select a font it will just, by default, use the ligatures that this font provides according to the logic embedded in the font. >> The documentation of Fira Code does recommend composition-function-table here: https://github.com/tonsky/FiraCode/wiki/Emacs-instructions, but it seems like a lot of extra work for each font, isn't it? > > That's for static compositions, not for automatic compositions. I was > talking about the latter, and consider the former to be a > semi-obsolete feature that we should eventually remove. I see. I need to read up on the difference.