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: Sat, 23 May 2020 19:18:22 +0300 Message-ID: <83blmezktt.fsf@gnu.org> References: <20200517165953.000044d2@web.de> <83blmi7hys.fsf@gnu.org> <837dx55qff.fsf@gnu.org> <834ks95cmz.fsf@gnu.org> <4faa291f-f2df-36d1-73d5-332b93a9b6d8@gmail.com> <83wo544hx5.fsf@gnu.org> <831rnc43ih.fsf@gnu.org> <83ftbs2jr5.fsf@gnu.org> <838shk2ga3.fsf@gnu.org> <835zcn3iao.fsf@gnu.org> <83wo5321qp.fsf@gnu.org> <639a2445-3773-2455-92f6-38b3c5b5f7b5@gmail.com> <83mu5z171j.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="21542"; 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 Sat May 23 18:18:41 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 1jcWrB-0005UT-M5 for ged-emacs-devel@m.gmane-mx.org; Sat, 23 May 2020 18:18:41 +0200 Original-Received: from localhost ([::1]:39320 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jcWrA-0001A7-OY for ged-emacs-devel@m.gmane-mx.org; Sat, 23 May 2020 12:18:40 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42278) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jcWql-0000lW-M8 for emacs-devel@gnu.org; Sat, 23 May 2020 12:18:15 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:45537) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jcWql-0004WT-40; Sat, 23 May 2020 12:18:15 -0400 Original-Received: from [176.228.60.248] (port=2221 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jcWqk-0002eU-Jc; Sat, 23 May 2020 12:18:14 -0400 In-Reply-To: (message from =?utf-8?Q?Cl=C3=A9ment?= Pit-Claudel on Sat, 23 May 2020 10:34:23 -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:251281 Archived-At: > Cc: pipcet@gmail.com, alan@idiocy.org, emacs-devel@gnu.org > From: Clément Pit-Claudel > Date: Sat, 23 May 2020 10:34:23 -0400 > > > Emacs doesn't need a special list for each font. I already said that > > several times. Please look at some examples of composition rules we > > already have, for example the Arabic rules at the very end of > > misc-lang.el. Do you see any fonts mentioned there? These rules work > > with any font that supports Arabic. > > The only thing I'm talking about is symbol compositions in programming fonts, and for these, we *will* need a custom list for each font, right? No, we won't need custom lists. Not if we will use the same character composition machinery as we use now for Arabic and other scripts that require it. > > And finally, if a given font doesn't support some ligature, the > > original characters will be displayed "normally", so nothing is lost, > > and there's no need to tune the list of ligatures to each and every > > font. I said that as well several times already. > > As long as you can produce a superset of all ligatures, yes. My claim is that this superset is ".+". It cannot be literally ".+", if you are talking about symbols, because (a) not every character starts a symbol, and (b) symbols cannot be of arbitrary length. > Otherwise, how do you handle the fact that Fira Code handles arrows > of arbitrary lengths? We won't handle arrows of arbitrary length, no. Not as long as we keep the current design of the display engine.