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: Sun, 24 May 2020 18:33:07 +0300 Message-ID: <831rn9xs98.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> <83wo544hx5.fsf@gnu.org> <831rnc43ih.fsf@gnu.org> <83ftbs2jr5.fsf@gnu.org> <83lflj16jn.fsf@gnu.org> <83eerb145r.fsf@gnu.org> <831rnb0zld.fsf@gnu.org> <83mu5yzquj.fsf@gnu.org> <838shizk35.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="125801"; mail-complaints-to="usenet@ciao.gmane.io" Cc: cpitclaudel@gmail.com, alan@idiocy.org, emacs-devel@gnu.org To: Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun May 24 17:33:32 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 1jcsd1-000Wbs-Nf for ged-emacs-devel@m.gmane-mx.org; Sun, 24 May 2020 17:33:31 +0200 Original-Received: from localhost ([::1]:58790 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jcsd0-0006Lx-RK for ged-emacs-devel@m.gmane-mx.org; Sun, 24 May 2020 11:33:30 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48928) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jcscX-0005uw-L9 for emacs-devel@gnu.org; Sun, 24 May 2020 11:33:01 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:33462) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jcscW-0002K9-Hn; Sun, 24 May 2020 11:33:00 -0400 Original-Received: from [176.228.60.248] (port=4424 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jcscV-0003ax-R2; Sun, 24 May 2020 11:33:00 -0400 In-Reply-To: (message from Pip Cet on Sat, 23 May 2020 22:38:18 +0000) 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:251322 Archived-At: > From: Pip Cet > Date: Sat, 23 May 2020 22:38:18 +0000 > Cc: cpitclaudel@gmail.com, alan@idiocy.org, emacs-devel@gnu.org > > On Sat, May 23, 2020 at 4:34 PM Eli Zaretskii wrote: > > > From: Pip Cet > > > Date: Sat, 23 May 2020 15:13:38 +0000 > > > Cc: cpitclaudel@gmail.com, alan@idiocy.org, emacs-devel@gnu.org > > > Because what the current layout code does by default is to break > > > along any glyph boundary, and I don't see how that's broken in any > > > way. > > > > The code assumes that breaking on some glyph leaves the buffer > > iterator ('struct it') in a state that we can simply continue to the > > next buffer position. > > Yes. I see no reason to change that. > > > But if you already picked up several characters > > via look-ahead, that is not true, and you will have to return back > > several character positions, in order to continue on the next screen > > line. > > You're describing why look-ahead is difficult: a while ago, you > appeared to be saying it wasn't. This confuses me. > > Obviously, when I say "look-ahead", I mean receiving the next display > elements an iterator would produce if it were actually advanced, > without advancing it. That's not what you said earlier: > > > > > You write: "(b) is not really feasible without redesigning the entire > > > > > Emacs display engine". I don't see how that's true at all. All we need > > > > > is some limited look-ahead. > > > > > > > > We already have look-ahead: that's what the regexp part of the > > > > composition rules are about. That is not the crucial problem. > > > > > > But it's the only problem I see! > > > > Then maybe I don't understand what you mean by look-ahead. Is that > > the decision how to choose those 32 characters of "context"? > > Yes. Here you said that look-ahead means how to _choose_ the context. Now you are saying something very different: that look-ahead is how to advance the iterator without advancing it. It's a small wonder we are going in circles when the same term is used for two very different things. > > If we want the shaper to handle all the text we display, > > Do we? A while back you said Lisp control over compositions was an > important feature, and I'm inclined to think we shouldn't break the > existing composition code. > > > we should go all the way and do it for any text, ASCII, non-ASCII, > > symbols, emoji, everything. > > Are you suggesting I'm somehow limiting myself to ASCII? Let me assure > you that's not the case. Then I really don't understand what problem are you trying to solve. Let's try again from the beginning: which parts of the code that implements automatic compositions are you trying to avoid, and why? Is that the part that identifies the "context" via regular expressions? If so, then this problem needs to be solved by some alternative; using an arbitrary chosen fixed number of characters is not suitable for production. You haven't yet shown any viable alternative. Assuming that the alternative for selecting the "context" is found, and composite.c is augmented to apply it instead of the regexps, why not use the rest of the automatic composition code to produce the glyphs and display them? The code which does that exists and works, and is tested by years of use. It already solves the problems of look-ahead, of wrapping long lines, and others, including (but not limited to) the dreaded bidi thing. Why reinvent that wheel when we already have it, and it works well? > > and on top of that solve only a small part of the > > underlying problem. > > Ligatures and kerning (right now, for LTR text). Is that a small > problem because of the lack of RTL support? Yes, of course. An acceptable solution should support any text Emacs supports. What's more, we already have the code which implements all that, so I don't understand why you want to bypass it. Please explain.