From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Supporting stylistic sets Date: Mon, 26 Sep 2022 20:07:41 +0300 Message-ID: <835yhakqsi.fsf@gnu.org> References: <83wn9up0es.fsf@gnu.org> <83h70yotd4.fsf@gnu.org> <83a66pq2b1.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="blaine.gmane.org:116.202.254.214"; logging-data="7548"; mail-complaints-to="usenet@ciao.gmane.io" Cc: lumarzeli30@gmail.com, emacs-devel@gnu.org To: Nicolas Ouellet-payeur Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Sep 26 19:24:11 2022 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 1ocrpy-0001j5-T0 for ged-emacs-devel@m.gmane-mx.org; Mon, 26 Sep 2022 19:24:11 +0200 Original-Received: from localhost ([::1]:43076 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ocrpx-0001CF-Un for ged-emacs-devel@m.gmane-mx.org; Mon, 26 Sep 2022 13:24:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41078) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ocraE-0005JJ-L9 for emacs-devel@gnu.org; Mon, 26 Sep 2022 13:07:54 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:38902) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ocraD-0005Eq-5y; Mon, 26 Sep 2022 13:07:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=XwoevAzEAU9/lzCDlM97YTS7/FmOru1aTTd7DIKQxGE=; b=XgC4/peDBlyqUQkuecZQ IgP5Pp66e21Ml9CorcLXjaUYb2DaTTPZAElxItRGGiHkATsshUQwLsfIoy/3eMXKidXlv94VC+8Tx kAI62xVEnnOH5ztltFv806l3r4ZXZFsimXXRq6WHHcV38J82umTaGfRhW/wCybNnHk/W5Xv+gg1FM w/vRNucEl/nPgrQ5aFZAkI+SM6USf3gVpvMYfoICrV+ZbnjiZ9C9JYH0d1fA1E7GTgIgzCJwOd80U zfjqJfUSHLe3w0rGN383vgIj5E5SA9ub6rrBMyh3KXXlWgjxAB+8Dg3hWcRqNAIjiMhVI6Xc6uOXu M7b0icKAgiZRsw==; Original-Received: from [87.69.77.57] (port=4517 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ocraB-0002Jy-1B; Mon, 26 Sep 2022 13:07:52 -0400 In-Reply-To: (message from Nicolas Ouellet-payeur on Mon, 26 Sep 2022 12:35:34 -0400) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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:296292 Archived-At: > From: Nicolas Ouellet-payeur > Date: Mon, 26 Sep 2022 12:35:34 -0400 > Cc: समीर सिंह Sameer Singh , > emacs-devel@gnu.org > > > To measure the slowdown, run the benchmark of scrolling through a > > large file, like xdisp.c, one line at a time, and compare with the > > current code. > > It's not as bad as I feared, but it's still pretty bad. Scrolling 2000 > lines through xdisp.c is ~2.3x slower in the patched version. The jank > is noticeable though, especially because scrolling *should* be limited > by the keyboard repeat rate. I think you tried a relatively benign situation. To see how this could _really_ be slow, make a composition rule that will catch any sequence of any non-whitespace characters. This slowness is the main disadvantage of our current method of handling character compositions. (It also has numerous advantages.) If we want to progressively increase the use of text-shaping engines when rendering text, we will need to redesign this part, because the way we do this now cannot be extended in those directions without causing significant slowdown. > > But what do you do if the user wants to disable ligation, or control > > which ligatures should and shouldn't happen? > > To disable ligation, one can turn off font features selectively. For > instance disabling 'rlig' in Fira Code disables the code ligatures. We > could disable it by default on the mode-line, for instance. Or just a > section of the default mode-line. That would disable ligation in complex script shaping, where it is a must. For example, displaying the Arabic script requires ligatures. So I think disabling ligation this way is unworkable; we must find some other ways of doing that. > - Ignore the shaping engine. Read the GSUB table from the font file > ourselves, and populate `composition-function-table' with that. > Supporting *everything* is really hard, but basic use-cases might work > fine out-of-the-box. That's a non-starter, IMO. We don't want to develop our own font-related and text-shaping-related capabilities, as it's not our expertise and we will never be able to have enough knowledge and development resources to do it. We must rely on external shaping engines such as HarfBuzz. > - Give up on OOTB ligature support (status quo). The status quo is NOT that we don't support ligatures. The support is available; you can have it at the price of a few minutes' work by installing the composition rules in composition-function-table. What is missing is a convenient interface and UI for users to control where and which ligatures will be available. See the related TODO item.