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 21:28:46 +0300 Message-ID: <831qrykn1d.fsf@gnu.org> References: <83wn9up0es.fsf@gnu.org> <83h70yotd4.fsf@gnu.org> <83a66pq2b1.fsf@gnu.org> <835yhakqsi.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="39656"; 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 20:56:27 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 1octHG-000A9d-Vn for ged-emacs-devel@m.gmane-mx.org; Mon, 26 Sep 2022 20:56:27 +0200 Original-Received: from localhost ([::1]:58726 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1octHF-00023Z-UW for ged-emacs-devel@m.gmane-mx.org; Mon, 26 Sep 2022 14:56:25 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36748) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ocsqe-0000UQ-Vk for emacs-devel@gnu.org; Mon, 26 Sep 2022 14:28:57 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:58650) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ocsqe-0001Q2-M6; Mon, 26 Sep 2022 14:28:56 -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=XJ72/6rm7P5SwQVQAVPlM8wuJrR9GKaE6ekFBUA7BBc=; b=OI88w/DqryfkieWZAhyB Af9Q/7igX180QSvgQhWdk8bZsWcPYbGultoPxkkd3Q1p89FK/muLkJ8jBkPxvZ36z0PZhEE/Ef9wF UJ64KHLAGYKQQsmwE45VGBUGsuGLhR/HyyQ4GbkSYPmcJFypHibBBzFqPtFB3Y0kMlbm4k6Jr6Rj+ VwD623JeV3JyL8E64aWIkJ9Khg5sMOx9F0MF6/L3ZFfDmp/yQ8qpiA+uDdyxac4bhLuBOlIvdFfcb SCVcRACzcbfPX7xDkAE5CNTEEIj/NoLrr5kaCWPqVLW5w0H6lGo96MtKF0BqwRgQ+0X9vUQ2HCkYG 1bYaqvS9w6eG4Q==; Original-Received: from [87.69.77.57] (port=1628 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 1ocsqd-0002cm-Qn; Mon, 26 Sep 2022 14:28:56 -0400 In-Reply-To: (message from Nicolas Ouellet-payeur on Mon, 26 Sep 2022 13:46:40 -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:296300 Archived-At: > From: Nicolas Ouellet-payeur > Date: Mon, 26 Sep 2022 13:46:40 -0400 > Cc: समीर सिंह Sameer Singh , > emacs-devel@gnu.org > > > That would disable ligation in complex script shaping, where it is a > > must. > > That's why the default mode-line would have a text property on the parts > that are likely to ligate. > > e.g. if my mode-line reads like: > > -:--- foo.c All L1 (C Abbrev) > > Then we'd apply this text property on the "-:---" part. First, this is the first time that you mention a text property in this discussion. We don't have such a text property in Emacs, so it would have to be added, character-composition code will need to be amended to be aware of the property. And second, it is not good enough to have the property on the "-:---" part, because that's where the input-method mnemonics are displayed, and those frequently do need ligations, if they use characters from scripts which require that. > > 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 > > What do you mean by "this part" specifically? The part where we call > into Lisp for any character in `composition-function-table'? Or the fact > that we do a regex match each time? Mainly the former. > > The status quo is NOT that we don't support ligatures. The support is > > available > > Of course. By OOTB (out-of-the-box) I meant reading the GSUB table so we > can apply ligatures *without* requiring manual configuration. i.e. > making the shaping engine do the heavy lifting. The shaping engine will do the heavy lifting anyway, but we must give users control on what is and what isn't ligated, so just asking the shaping engine to ligate everything the font supports is also out of the question. > Are we OK with the status quo then, where ligatures have to be manually > configured? In that case, I could send a patch to remove that item from > etc/TODO. The item in TODO explains in detail what it means by "OOTB". What is described there is missing from the current Emacs, and I hope it will be added. But the way to add it must allow user control on what ligatures will be produced and in what places. It also should allow this control via a UI that is much easier to use than the current raw support which requires manually writing entries for composition-function-table. It's all in the TODO item's text, and I don't understand how that could lead you to the conclusion that we are "OK with the status quo". All I said that it's incorrect to say that we don't have any support for ligatures.