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:34:22 +0300 Message-ID: <838shizk35.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="91439"; 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 18:35: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 1jcX6z-000Nbp-KT for ged-emacs-devel@m.gmane-mx.org; Sat, 23 May 2020 18:35:01 +0200 Original-Received: from localhost ([::1]:46068 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jcX6y-0005so-MJ for ged-emacs-devel@m.gmane-mx.org; Sat, 23 May 2020 12:35:00 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43500) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jcX6P-0005TD-TN for emacs-devel@gnu.org; Sat, 23 May 2020 12:34:25 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:45784) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jcX6O-0007p0-1w; Sat, 23 May 2020 12:34:24 -0400 Original-Received: from [176.228.60.248] (port=3207 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jcX6H-0002iq-2u; Sat, 23 May 2020 12:34:22 -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:251282 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 > > > > Calling the shaper less often is an important optimization, too. For > > > whitespace-delimited words, we only need to call it once. > > > > This doesn't work when the produced sequence of glyphs doesn't fit on > > the screen line. > > > What the current layout code does in this case won't > > work well when you need to break a long sequence of glyphs in the > > middle and then continue on the next line from where you left off on > > this one. > > You mean in visual-mode? Not just in visual-line-mode, but also for the default line continuation. > 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. 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. The whole convoluted logic of display_line (and a similar one in move_it_in_display_line_to) is based on the assumption that this line-wrap decisions are made as soon as a single glyph is produced; that code will need to be rewritten if this assumption breaks. And since the code is already hairy, to say the least, I cannot even imagine what it will look like after such rewriting. This is just a small example of how deep are the current design assumptions entrenched in the code. I don't see how this can be resolved to yield code that is readable and maintainable without changing the design. Again, maybe I'm missing something. > > In short, I really don't see how this could ever work, except in a > > very limited set of simple use cases. E.g., what do you do with > > bidirectional text? ignore it? > > A bidi boundary is a hard boundary for HarfBuzz, and no shaping > happens across it. Is that what you mean by "ignore it"? I don't mean the boundary, I meant the fact that clusters need to be reordered. > > I don't see how it could work in production while supporting all the > > use cases we already do. > > It only comes in for use cases not handled otherwise, i.e. those where > the iterator is at an IT_CHARACTER. All other use cases are > unaffected, because they mean we're overriding the font decision > anyway. I see no reason to add such patches just to handle some simple enough use cases. If we want the shaper to handle all the text we display, we should go all the way and do it for any text, ASCII, non-ASCII, symbols, emoji, everything. The current codebase is already very difficult to understand and modify; you seem to suggest to make it even more so, and on top of that solve only a small part of the underlying problem. That makes very little sense to me.