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 20:32:23 +0300 Message-ID: <831rnazheg.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> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="77640"; 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 Sat May 23 19:33:02 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 1jcY17-000K5R-TI for ged-emacs-devel@m.gmane-mx.org; Sat, 23 May 2020 19:33:01 +0200 Original-Received: from localhost ([::1]:56308 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jcY16-0002NQ-TL for ged-emacs-devel@m.gmane-mx.org; Sat, 23 May 2020 13:33:00 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47270) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jcY0b-0001yg-0x for emacs-devel@gnu.org; Sat, 23 May 2020 13:32:29 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:46600) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jcY0Z-0000Ad-JV; Sat, 23 May 2020 13:32:27 -0400 Original-Received: from [176.228.60.248] (port=2883 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jcY0O-0005JC-Ov; Sat, 23 May 2020 13:32:17 -0400 In-Reply-To: (message from Pip Cet on Sat, 23 May 2020 15:13:38 +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:251284 Archived-At: > From: Pip Cet > Date: Sat, 23 May 2020 15:13:38 +0000 > Cc: cpitclaudel@gmail.com, alan@idiocy.org, emacs-devel@gnu.org > > As I said, the problem I have is to get look-ahead working, which you > think isn't a problem. I've got an idea for it, but it doesn't work > (yet); my theory is the bidi.c code fails to keep its state in the > iterator and can't deal with multiple parallel iterators. > > > I could be wrong, though, so I'm looking > > forward to see you present a series of patches that do support the > > existing use cases and the ligatures as well, and don't cause any > > slowdown in redisplay. > > As I said, what's stopping me is the look-ahead problem, and in > particular some code in bidi.c that doesn't play along well with > look-ahead. I don't think you understand the depth of the issue. If we are going to send large chunks of text to the shaping engine, then none of the insane complexity of bidi.c makes sense; we should simply throw all of it away and use a very different, batch-style reordering code, of the kind you can find in the freebidi library. The sole reason for bidi.c's existence is to produce character positions in the _visual_ order, one position at a time, something that no other bidi-aware editor does. Moreover, not even the basic iteration, one level above bidi.c, where we call get_next_display_element, then PRODUCE_GLYPHS, then set_iterator_to_next -- not even that makes sense. This basic loop exists only because we examine characters one by one, switching from buffer text to overlay or display strings, then back, as needed, and applying faces as we go. Doing this in large chunks calls for a very different structure of the code, and very different separation into layers. This needs to be carefully designed in advance in a clean and well-defined way, not lumped one patch upon another until it kinda works...