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.devel Subject: Re: Ligatures (was: Unify the Platforms: Cairo+FreeType+Harfbuzz Everywhere (except TTY)) Date: Fri, 22 May 2020 14:44:01 +0300 Message-ID: <83y2pk2nzy.fsf@gnu.org> 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> 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="41241"; mail-complaints-to="usenet@ciao.gmane.io" Cc: alan@idiocy.org, pipcet@gmail.com, emacs-devel@gnu.org To: =?utf-8?Q?Cl=C3=A9ment?= Pit-Claudel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri May 22 13:44:46 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 1jc66Y-000Ac8-D8 for ged-emacs-devel@m.gmane-mx.org; Fri, 22 May 2020 13:44:46 +0200 Original-Received: from localhost ([::1]:47134 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jc66X-0005SJ-EC for ged-emacs-devel@m.gmane-mx.org; Fri, 22 May 2020 07:44:45 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36688) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jc65o-0004ql-1o for emacs-devel@gnu.org; Fri, 22 May 2020 07:44:00 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:44186) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jc65n-0002cc-0g; Fri, 22 May 2020 07:43:59 -0400 Original-Received: from [176.228.60.248] (port=3039 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jc65m-0005EB-ES; Fri, 22 May 2020 07:43:58 -0400 In-Reply-To: <4faa291f-f2df-36d1-73d5-332b93a9b6d8@gmail.com> (message from =?utf-8?Q?Cl=C3=A9ment?= Pit-Claudel on Thu, 21 May 2020 16:51:47 -0400) 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:251211 Archived-At: > 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? 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. See, this is exactly part of the job that still awaits us: to figure out the various use cases for displaying ligatures in a buffer, and then provide the necessary user-facing features to adapt Emacs to each use case. The infrastructure for this already exists: it's the auto-composition-mode and composition-function-table that underlies it (although we may need to add something so that composition-function-table could be modified on per-buffer basis), but we lack an easy-to-use UI and customization features that will allow users to use that machinery in practice. See the TODFO item about ligatures; volunteers are welcome to work on that. > 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.