From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Vasilij Schneidermann Newsgroups: gmane.emacs.devel Subject: Re: Ligatures (was: Unify the Platforms: Cairo+FreeType+Harfbuzz Everywhere (except TTY)) Date: Sat, 23 May 2020 13:24:12 +0200 Message-ID: <20200523112412.GA30384@odonien.localdomain> References: <83wo544hx5.fsf@gnu.org> <831rnc43ih.fsf@gnu.org> <83ftbs2jr5.fsf@gnu.org> <83lflj16jn.fsf@gnu.org> <834ks7110w.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="xHFwDpU9dbj6ez1V" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="110111"; mail-complaints-to="usenet@ciao.gmane.io" Cc: cpitclaudel@gmail.com, alan@idiocy.org, pipcet@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat May 23 13:24:53 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 1jcSGr-000ScH-Jm for ged-emacs-devel@m.gmane-mx.org; Sat, 23 May 2020 13:24:53 +0200 Original-Received: from localhost ([::1]:57622 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jcSGq-0001Lz-LM for ged-emacs-devel@m.gmane-mx.org; Sat, 23 May 2020 07:24:52 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48018) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jcSGQ-0000ve-7b for emacs-devel@gnu.org; Sat, 23 May 2020 07:24:26 -0400 Original-Received: from mout-p-202.mailbox.org ([80.241.56.172]:38756) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_CHACHA20_POLY1305:256) (Exim 4.90_1) (envelope-from ) id 1jcSGM-0002dI-Tz; Sat, 23 May 2020 07:24:25 -0400 Original-Received: from smtp2.mailbox.org (smtp2.mailbox.org [80.241.60.241]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by mout-p-202.mailbox.org (Postfix) with ESMTPS id 49Tgwx6twPzQl2B; Sat, 23 May 2020 13:24:17 +0200 (CEST) X-Virus-Scanned: amavisd-new at heinlein-support.de Original-Received: from smtp2.mailbox.org ([80.241.60.241]) by spamfilter05.heinlein-hosting.de (spamfilter05.heinlein-hosting.de [80.241.56.123]) (amavisd-new, port 10030) with ESMTP id 7AUSXUem-sC7; Sat, 23 May 2020 13:24:14 +0200 (CEST) Mail-Followup-To: Eli Zaretskii , emacs-devel@gnu.org, pipcet@gmail.com, cpitclaudel@gmail.com, alan@idiocy.org Content-Disposition: inline In-Reply-To: <834ks7110w.fsf@gnu.org> X-Rspamd-Queue-Id: 759941738 X-Rspamd-Score: -6.94 / 15.00 / 15.00 Received-SPF: pass client-ip=80.241.56.172; envelope-from=mail@vasilij.de; helo=mout-p-202.mailbox.org X-detected-operating-system: by eggs.gnu.org: First seen = 2020/05/23 07:24:18 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action 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:251264 Archived-At: --xHFwDpU9dbj6ez1V Content-Type: text/plain; charset=utf-8 Content-Disposition: inline > The reason is how the current Emacs display engine is designed: it > cannot pass large substrings of buffer text to the shaping engine > without incurring performance penalties and/or disrupting the way the > layout decisions, as currently designed, work. the current design of > the display engine is that we examine the stuff to be displayed one > grapheme cluster at a time, and make the layout decisions after each > grapheme cluster's metrics is produced. Unless someone begins working > on a new design of the Emacs display, I see no good way for overcoming > these problems, based on what I know about the display code. Thanks for describing the problem in detail. Out of curiosity, is this the same reason why font fallback is handled on a per-script basis for most cases and with carefully chosen ranges for emoji? I see a similar problem there, with updates being necessary for every Unicode release. > Of course, it's possible that I'm missing something in the current display > code, which could luckily allow us to support any ligature made up from any > number of characters without any significant design changes. So please by > all means study the current code, see if something like that is possible, > describe such a possible solution, and I'll gladly admit my mistake. I don't > claim a 110% understanding of all the subtleties of the current code, so it > is perfectly possible that I'm missing something. I don't think it is good > for Emacs to have just one person who knows these details, especially if that > person is myself. We need to enlarge the circle of our experts on this, and > then perhaps a practical solution could present itself. Although I'm > skeptical, to tell the truth. Given your previous explanation, a regex-based approach heuristic is the best we can hope for then. From what I understand the display engine uses a rectangular grid, not unlike what terminal emulators do. Are there any tricks to steal from existing terminal emulators? For example there is an open pull request [1] for alacritty using Harfbuzz and FreeType for ligature support. > If I _am_ right, and the complete solution is impossible, we could, of course > decide that partial solutions based on heuristics are not good enough for us, > and wait for the redesign of the display code. I hope we will not do that, > because IMO partial solutions that satisfy 80% of the needs are much better > than no solutions. That is why I described how this stuff could work under > the current limitations, albeit without supporting every possible use case. > Eventually, this is something the community should decide. The greatest challenge I see with redesigning the display engine is supporting textual terminals. One alternative design would be using something akin to a typesetting engine, like TeX's boxes and glue model or something from the roff family (which is used successfully in terminal emulators for `man`). Another approach is to build upon a browser engine and use copious amounts of CSS and JavaScript to build an editor. Neither is known to be performant and power efficient enough for continuous redisplay. It's no wonder that custom designs are used, for example in GUI toolkits. Maybe that is the way forward? Vasilij [1]: https://patch-diff.githubusercontent.com/raw/alacritty/alacritty/pull/2677.patch --xHFwDpU9dbj6ez1V Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEE0dAcySl3bqM8O17WFmfJg6zCifoFAl7JB9MACgkQFmfJg6zC ifpd8gf/WIHjdzXMFbdnrGYj1hgcHo11UjBtdhsEYbqO/LiJYdz1UFTg6lieEU6h DwahoS/2EWFiOHdlPUwvXEuARhtZtsc6jYXQ2GEabGNuuXjg0JtpIIDBJpnraWzu lPC26NnyvfaTzD8rRHslGycn4XajZzUjmYE/d/kl3BZCByyXDnLb1AI7TPuqdRpd FbCWFXEcBG+1LALcqeCITfpRT93w/W/5k71Lc8Wv2BsVUVugXbG47ek/jsA1057l zdWQI3TaLvERE+HLheRKcC7q7uXQTrtp3kUsZk3VVxhNW3IKc37y9Mo8ApwuDEse cfvcF+M1k3QJt38YNE/2yPftBcZ9lw== =zwg+ -----END PGP SIGNATURE----- --xHFwDpU9dbj6ez1V--