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 Date: Mon, 18 May 2020 20:18:35 +0300 Message-ID: <83y2pp88lw.fsf@gnu.org> References: <20200517124125.000013a4@web.de> <97C7EAB7-10AB-4702-ABC8-EB6C1C50ABDB@gnu.org> <20200517165953.000044d2@web.de> <83lflqblp0.fsf@gnu.org> <83ftbybio3.fsf@gnu.org> <83zha69xs2.fsf@gnu.org> <83367x9qeq.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="ciao.gmane.io:159.69.161.202"; logging-data="106882"; mail-complaints-to="usenet@ciao.gmane.io" Cc: pipcet@gmail.com, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon May 18 19:19:34 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 1jajQL-000Ri0-Im for ged-emacs-devel@m.gmane-mx.org; Mon, 18 May 2020 19:19:33 +0200 Original-Received: from localhost ([::1]:48898 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jajQK-0001Zx-Kp for ged-emacs-devel@m.gmane-mx.org; Mon, 18 May 2020 13:19:32 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37526) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jajPV-0000lq-MS for emacs-devel@gnu.org; Mon, 18 May 2020 13:18:44 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:33550) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jajPT-0008S8-MJ; Mon, 18 May 2020 13:18:40 -0400 Original-Received: from [176.228.60.248] (port=2600 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jajPT-0006U7-5Y; Mon, 18 May 2020 13:18:39 -0400 In-Reply-To: (message from Stefan Monnier on Mon, 18 May 2020 13:05:53 -0400) 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:250786 Archived-At: > From: Stefan Monnier > Cc: pipcet@gmail.com, emacs-devel@gnu.org > Date: Mon, 18 May 2020 13:05:53 -0400 > > So, maybe we don't need very much info: all we need is a boolean which > tells us whether the glyph should be treated atomically or not. > When not treating it atomically, we would (somewhat arbitrarily) divide > the glyph horizontally into N equal sized "subglyphs" and draw the > cursor on the corresponding subglyph. That strikes me as not a very user-friendly UX. Especially if you keep in mind that glyphs can be composed into a grapheme cluster using 2D offsets, not just left-right one-dimensional offsets. An alternative which might be nicer is to "split" the composition: display it as if a ZWNJ character was inserted at point. Thus, moving forward one buffer position into the ffi would show f followed by a thin bar cursor followed by the fi; moving forward one more buffer position would show ff followed by a thin bar cursor followed by i. Etc. > If Harfbuzz could tell us more precisely how to divide the glyph into > subglyphs, we could do a better job, of course. I don't think it's possible because AFAIK fonts don't store this information. It should be possible, of course, to have a private database of such offsets, but I don't really see how it could work in general. Maybe I'm missing something, though. If someone wants to have a definitive answer, I suggest to ask on the HarfBuzz mailing list.