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.help Subject: Re: Composed Sequences Date: Sat, 26 Feb 2022 22:02:40 +0200 Message-ID: <837d9hpfa7.fsf@gnu.org> References: <20220220110926.25c675be@JRWUBU2> <835yp9ya4x.fsf@gnu.org> <20220226002837.699ae2b1@JRWUBU2> <83r17qp268.fsf@gnu.org> <20220226151144.4c0b641e@JRWUBU2> <83fso5prnp.fsf@gnu.org> <20220226194616.4c6e0330@JRWUBU2> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26318"; mail-complaints-to="usenet@ciao.gmane.io" To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Sat Feb 26 21:03:39 2022 Return-path: Envelope-to: geh-help-gnu-emacs@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 1nO3I2-0006Zs-Vm for geh-help-gnu-emacs@m.gmane-mx.org; Sat, 26 Feb 2022 21:03:39 +0100 Original-Received: from localhost ([::1]:40862 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nO3I1-0003KI-FL for geh-help-gnu-emacs@m.gmane-mx.org; Sat, 26 Feb 2022 15:03:37 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:35328) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nO3HM-0003Jw-OB for help-gnu-emacs@gnu.org; Sat, 26 Feb 2022 15:02:56 -0500 Original-Received: from [2001:470:142:3::e] (port=33860 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nO3HM-0001Og-Fg for help-gnu-emacs@gnu.org; Sat, 26 Feb 2022 15:02:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=IXtV0I7yxU4bH/95mh4hAb7J8TC7cZckRA7EA5EBj9o=; b=fkwbrlUhtUWo 2Bvv3CN3bi5LxghInQjMRZftUra5zQdY/uZx2H915v+X7TYzUgh+ENxCVZM0RZ4vbTx+8OHuX+PMp nft9V1pj32AbloVA05fI04FLxZh3sb2UtUaZqnuleodbTMbWlfoMDY/1yPkNsWMUewOC5rwJqDziE CkLdzT07Mq+lgs8GBCtGToZC67cr8RQ5OIyorNpda3iZWtGX4M5QzbuL1JcuvPPF5ru2Bw3ZbT/mC 3TCY5n6gCzHPNAxKj+EdQJznzNXkh+N/Dv5x23waS2PMbCY7KHGD6I49Ll8sQoXi4Dofa7/YbrHlj iGkcwWmQF1CCk+VSwV975w==; Original-Received: from [87.69.77.57] (port=3191 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 1nO3HL-0001Fx-UX for help-gnu-emacs@gnu.org; Sat, 26 Feb 2022 15:02:56 -0500 In-Reply-To: <20220226194616.4c6e0330@JRWUBU2> (message from Richard Wordingham on Sat, 26 Feb 2022 19:46:16 +0000) X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.io gmane.emacs.help:136211 Archived-At: > Date: Sat, 26 Feb 2022 19:46:16 +0000 > From: Richard Wordingham > > > > > Emacs > > > > obeys the decisions of the font designers. > > > > Unless they recorded the positions of the boundaries between the > > > parts of a ligature! > > > I don't understand what you mean by that. > > The GDEF table of an OpenType font records the boundary between the > components of a ligature glyph, via the 'ligature caret list' table > therein. These data, if they exist, are amongst the 'decisions of the > font designers'. Emacs doesn't (yet) use that information, so it cannot (yet) let you move "inside" the ligature, if the ligature is a single grapheme. > Glossary: > > cluster - sequence of coded characters presented to the shaping engine > to be shaped. That's not the terminology we use in Emacs. A grapheme cluster is the output of shaping, not the input. The input is just a match for a regular expression that expresses our idea of the shortest sequence of characters the shaper needs to see to do its job correctly. > In principle, a glyph may be shared between two graphemes, but I doubt > that Emacs has a mechanism to support that. It doesn't, and I don't think HarfBuzz can produce such results (IIUC what you mean). > > Emacs behaves according to what the shaping engine tells us about the > > number of graphems in the cluster. Each grapheme is (by default) a > > single unit for the purposes of cursor motion: Emacs will not let you > > "enter" the grapheme, even if it is make out of several glyphs. But > > there's nothing in particular that Emacs expects from the number and > > order of the graphemes in a cluster, we just use what the shaping > > engine hands back to us. And the cursor motion in Emacs is by default > > in logical order, i.e. in the increasing order of buffer positions of > > the original codepoints. > > I hope you mean "several characters", not "several glyphs". I mean both: in general, the shaping engine can take N codepoints (a.k.a. "characters") and return M glyphs, arranged as K graphemes, to display those N codepoints. > The exception is related to disable-point-adjustment and its > relatives, and I think also to undisplayed buffers. In Emacs 29, there's now a variable to allow cursor movement inside a composed sequence even when disable-point-adjustment is nil (as it is by default).