Received: (at 38485) by debbugs.gnu.org; 4 Dec 2019 17:05:33 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Dec 04 12:05:33 2019 Received: from localhost ([127.0.0.1]:42588 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1icY5k-0008Ur-My for submit <at> debbugs.gnu.org; Wed, 04 Dec 2019 12:05:32 -0500 Received: from eggs.gnu.org ([209.51.188.92]:34221) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1icY5h-0008Uc-PE for 38485 <at> debbugs.gnu.org; Wed, 04 Dec 2019 12:05:30 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:50732) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>) id 1icY5c-0005FU-MV; Wed, 04 Dec 2019 12:05:24 -0500 Received: from [176.228.60.248] (port=3248 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from <eliz@HIDDEN>) id 1icY5Z-0000w2-Ja; Wed, 04 Dec 2019 12:05:23 -0500 Date: Wed, 04 Dec 2019 19:05:14 +0200 Message-Id: <83sgm0hvhx.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: =?utf-8?Q?Cl=C3=A9ment?= Pit-Claudel <cpitclaudel@HIDDEN> In-reply-to: <478afae1-0080-c825-5a53-1bc8e897a1cc@HIDDEN> (message from =?utf-8?Q?Cl=C3=A9ment?= Pit-Claudel on Wed, 4 Dec 2019 11:57:12 -0500) Subject: Re: bug#38485: Customizing glyph widths References: <3183ba6c-6aea-fa25-bb32-7e5ff7c04ad6@HIDDEN> <83y2vshyvn.fsf@HIDDEN> <478afae1-0080-c825-5a53-1bc8e897a1cc@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 38485 Cc: casouri@HIDDEN, 38485 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Cc: 38485 <at> debbugs.gnu.org > From: Clément Pit-Claudel <cpitclaudel@HIDDEN> > Date: Wed, 4 Dec 2019 11:57:12 -0500 > > On 2019-12-04 10:52, Eli Zaretskii wrote: > > > >> Now that I think of it, though, I could see the use for a text property. For example, prettify-symbols-mode could have an option to make each n-characters prettification n-characters wide, so that composing ~~> into ⟿ would produce a wide arrow occupying the exact same amount of space as the original uncomposed characters. > > > > So what kind of text property would that be, and where and how will it > > come into play in the above scenario? > > I'm thinking something like `:display-width 3' or maybe `display-width "~~>"' (the former would mean "as wide as three spaces in the default font"; the later, "as wide as `~~>' in the default font"). > These properties would be applied by prettify-symbols-mode in addition to composition. I don't understand why would prettify-symbols-mode want to do this via a text property, instead of via a buffer-local variable. > An interesting related feature is the ability to move the cursor inside composed characters. For example, when composing -> into →, assuming a font such as Fira code with a two-characters wide → symbol, it would be nice to be able to position the point in the middle of the composed symbol. I often have this problem in Emacs with ||; I compose it into ‖, but I sometimes want to type |a|, and in those cases I tend to type || then press left and type a, but this doesn't work when || has been composed into ‖. > Other editors have this feature, but I'm not sure how they handle the distinction between a composition that shouldn't be "separable" (such as é = e + ') and one that should be (such as ↝ = ~ + >). This is an unrelated feature. We currently allow DEL to delete one characters even if it's composed with adjacent characters, but we don't allow moving inside the composition. (You can always toggle-auto-composition, though.)
bug-gnu-emacs@HIDDEN:bug#38485; Package emacs.
Full text available.Received: (at 38485) by debbugs.gnu.org; 4 Dec 2019 16:57:22 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Dec 04 11:57:22 2019 Received: from localhost ([127.0.0.1]:42573 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1icXxq-0008GV-7J for submit <at> debbugs.gnu.org; Wed, 04 Dec 2019 11:57:22 -0500 Received: from mail-qk1-f175.google.com ([209.85.222.175]:34298) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <cpitclaudel@HIDDEN>) id 1icXxo-0008GG-LO for 38485 <at> debbugs.gnu.org; Wed, 04 Dec 2019 11:57:21 -0500 Received: by mail-qk1-f175.google.com with SMTP id d202so596403qkb.1 for <38485 <at> debbugs.gnu.org>; Wed, 04 Dec 2019 08:57:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=3ty9XnrePs9k2Z/EDy+42Qxr8YJ6G8P49L9NVmN+Rck=; b=MA2/31lggM7cn9HPTgd4BzlHk+lOPOlR0AlnxVUIvai5EEVRWC1/MMzVfllvMY4/qe G4QPsHF8CxMsBQ37gVgMTSgPcLr9stdYFsxNw2FniQ6dSYSINgf3nOWadmRr+aPxhHTZ TU4lU1w38qk7IzULuXCb3uLJmsP5J27ix7110S8Mk2jXrI+HI09zBJYeSWBDm/zqC9Vm PHyNJ+eNt9NOMtMkFNJiFOpA1XkeUfStalZVCeuUiWfO4v+aGxbxvl66kJlSH7XUvX56 9HyCWr2bcYS/HW7hH6Y4ZMzwKIiZk6o4BdOWqeBeqbTeBvQ+0U5ZFjdm3brDSHj/h7Lt MugA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=3ty9XnrePs9k2Z/EDy+42Qxr8YJ6G8P49L9NVmN+Rck=; b=ToZZ/F0e2aKFbdYEtvpBgiBUdyY1/7vbUFKvCcapjmQ/K1/sltA7DqJLyea4le8+4J 22ClHT38Q4p9NZlTD8Kb2Ls2VbfKEK0/a7n2qXvvsjGjBfxk7DOyc2QK/f6frEYnYOH6 VRbyACaEZc2c63RK+luySVI1Axy1w8MjdKYbp9bvtinDVAR3dlFq2YJYLQk3BbuEPSr3 PDhl152YKaA0KRQwz48FQCK/hbg7gtqiIOTgKQ0r17DAJCmn/3giJDDqlhpe8XlGsgUT M5mjfwO53ufELSqe/1KVaEWL334CN6qvO+npBOZBMB6jqH7vVCA6CoC2H7E6YrC94Ian XJUQ== X-Gm-Message-State: APjAAAVjiLc7b3G/isZcSfucmqFnGW923KOf5CT/t3NMfuWarbtml61e Wmgj79+XOXMvgbyO6FOIzcsewLpf X-Google-Smtp-Source: APXvYqy2NjZfsocBiXBzW1RvQnA5++57qrtqNuVvUclIlO2nxg71Yk6OmHI08+kaGiDu9mSzgNVpbA== X-Received: by 2002:a05:620a:228:: with SMTP id u8mr4064576qkm.88.1575478633693; Wed, 04 Dec 2019 08:57:13 -0800 (PST) Received: from ?IPv6:2603:400a:0:82c:fff1:4e82:4e43:cc9e? ([2603:400a:0:82c:fff1:4e82:4e43:cc9e]) by smtp.googlemail.com with ESMTPSA id y10sm3786530qky.6.2019.12.04.08.57.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Dec 2019 08:57:13 -0800 (PST) Subject: Re: bug#38485: Customizing glyph widths To: Eli Zaretskii <eliz@HIDDEN>, Yuan Fu <casouri@HIDDEN> References: <3183ba6c-6aea-fa25-bb32-7e5ff7c04ad6@HIDDEN> <83y2vshyvn.fsf@HIDDEN> From: =?UTF-8?Q?Cl=c3=a9ment_Pit-Claudel?= <cpitclaudel@HIDDEN> Message-ID: <478afae1-0080-c825-5a53-1bc8e897a1cc@HIDDEN> Date: Wed, 4 Dec 2019 11:57:12 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.1 MIME-Version: 1.0 In-Reply-To: <83y2vshyvn.fsf@HIDDEN> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 38485 Cc: 38485 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On 2019-12-04 10:52, Eli Zaretskii wrote: > >> Now that I think of it, though, I could see the use for a text property. For example, prettify-symbols-mode could have an option to make each n-characters prettification n-characters wide, so that composing ~~> into ⟿ would produce a wide arrow occupying the exact same amount of space as the original uncomposed characters. > > So what kind of text property would that be, and where and how will it > come into play in the above scenario? I'm thinking something like `:display-width 3' or maybe `display-width "~~>"' (the former would mean "as wide as three spaces in the default font"; the later, "as wide as `~~>' in the default font"). These properties would be applied by prettify-symbols-mode in addition to composition. An interesting related feature is the ability to move the cursor inside composed characters. For example, when composing -> into →, assuming a font such as Fira code with a two-characters wide → symbol, it would be nice to be able to position the point in the middle of the composed symbol. I often have this problem in Emacs with ||; I compose it into ‖, but I sometimes want to type |a|, and in those cases I tend to type || then press left and type a, but this doesn't work when || has been composed into ‖. Other editors have this feature, but I'm not sure how they handle the distinction between a composition that shouldn't be "separable" (such as é = e + ') and one that should be (such as ↝ = ~ + >). Clément.
bug-gnu-emacs@HIDDEN:bug#38485; Package emacs.
Full text available.Received: (at 38485) by debbugs.gnu.org; 4 Dec 2019 15:52:28 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Dec 04 10:52:27 2019 Received: from localhost ([127.0.0.1]:42509 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1icWx1-0004hE-Jc for submit <at> debbugs.gnu.org; Wed, 04 Dec 2019 10:52:27 -0500 Received: from eggs.gnu.org ([209.51.188.92]:47837) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1icWwz-0004h0-MT for 38485 <at> debbugs.gnu.org; Wed, 04 Dec 2019 10:52:26 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:49736) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>) id 1icWwu-0002t5-Ec; Wed, 04 Dec 2019 10:52:20 -0500 Received: from [176.228.60.248] (port=2571 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from <eliz@HIDDEN>) id 1icWwt-0002lU-1T; Wed, 04 Dec 2019 10:52:20 -0500 Date: Wed, 04 Dec 2019 17:52:12 +0200 Message-Id: <83y2vshyvn.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: =?utf-8?Q?Cl=C3=A9ment?= Pit-Claudel <cpitclaudel@HIDDEN>, Yuan Fu <casouri@HIDDEN> In-reply-to: <3183ba6c-6aea-fa25-bb32-7e5ff7c04ad6@HIDDEN> (message from =?utf-8?Q?Cl=C3=A9ment?= Pit-Claudel on Tue, 3 Dec 2019 23:22:35 -0500) Subject: Re: bug#38485: Customizing glyph widths References: <3183ba6c-6aea-fa25-bb32-7e5ff7c04ad6@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 38485 Cc: 38485 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Clément Pit-Claudel <cpitclaudel@HIDDEN> > Date: Tue, 3 Dec 2019 23:22:35 -0500 > > Interestingly, both of these cases are handled quite nicely in emacs -nw, because there the display is purely grid-like. FTR, I'd like to clarify that Emacs doesn't "handle" the -nw case in any way, it's taken care for us of by the terminal itself. Assuming that the terminal has the same notion of character width as Emacs does, that is; if they use different tables, the characters will not align. > For my use case, it would be enough to have this available as a minor mode, but Yuan Fu mentioned the following on emacs-devel: "I’d like to see it as a face attribute instead of a mode. (Because I want to align my org table). Maybe there could be a face attribute (:grid WIDTH) that instructs the display engine to pad each glyph to have width that is a multiple of WIDTH in pixel, and if WIDTH is t, default to “base character width”? I remembered that ‘window-width’ gives width in char widths and had a look at its source. It knows the character width from FRAME_COLUMN_WIDTH; the comment says the value currently equals to the average width of the default font of the frame. I think this value can be used as the “base character width”." I don't think I understand the rationale for using a face. It sounds like a subset of the general case, and why would someone want this alignment only for one special face? Using a face also means that the same characters from a larger font will not be aligned. > Now that I think of it, though, I could see the use for a text property. For example, prettify-symbols-mode could have an option to make each n-characters prettification n-characters wide, so that composing ~~> into ⟿ would produce a wide arrow occupying the exact same amount of space as the original uncomposed characters. So what kind of text property would that be, and where and how will it come into play in the above scenario? Thanks.
bug-gnu-emacs@HIDDEN:bug#38485; Package emacs.
Full text available.Received: (at submit) by debbugs.gnu.org; 4 Dec 2019 04:23:05 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Dec 03 23:23:05 2019 Received: from localhost ([127.0.0.1]:41340 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1icMBs-0000sJ-KS for submit <at> debbugs.gnu.org; Tue, 03 Dec 2019 23:23:05 -0500 Received: from lists.gnu.org ([209.51.188.17]:43095) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <cpitclaudel@HIDDEN>) id 1icMBr-0000s9-OV for submit <at> debbugs.gnu.org; Tue, 03 Dec 2019 23:23:04 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:41687) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from <cpitclaudel@HIDDEN>) id 1icMBl-00019G-Of for bug-gnu-emacs@HIDDEN; Tue, 03 Dec 2019 23:23:02 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM, URIBL_BLOCKED autolearn=disabled version=3.3.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from <cpitclaudel@HIDDEN>) id 1icMBb-0003fN-0r for bug-gnu-emacs@HIDDEN; Tue, 03 Dec 2019 23:22:50 -0500 Received: from mail-qk1-x730.google.com ([2607:f8b0:4864:20::730]:33800) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from <cpitclaudel@HIDDEN>) id 1icMBa-00036o-Pj for bug-gnu-emacs@HIDDEN; Tue, 03 Dec 2019 23:22:46 -0500 Received: by mail-qk1-x730.google.com with SMTP id d202so5938603qkb.1 for <bug-gnu-emacs@HIDDEN>; Tue, 03 Dec 2019 20:22:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=fsFnPyzpGu0V2QMoNmeEc21B5gVmYdojvGJY/sobtqk=; b=Z+oFUdUxjUeY1q0KUpizEDp5L2Q1q+3sKOPLPlijAg1cYiOdZ5HVkkKx2I0xD8u2p1 f+5eUI6cYVI2LBAohe7QPm0MFv4062yr3j3DSRr19DLmA3A4vkbRHp8mTpqJP0MFyPkz 9Nso6OWMHoA5QOX0vLbkGFvr69xftL3awwTzM2oUGn2p1x4hctF133MYlMR5b0nS07Vy Mf8f9CbEnhml7noB3oEeacjNlRHExpAjZWMor/u3UxwgHRlTxS4GGH8yFeQmDRfwhL82 oL8580VkUD5gOyO+Sj79gOXUBRndqoaL9W/opNx/DHsk+c65w88Hprcq5ID04vuwgAPf mAlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=fsFnPyzpGu0V2QMoNmeEc21B5gVmYdojvGJY/sobtqk=; b=Ujwer9/NsaiWKcdWtAsAaXuWTlOyUUkGWw2m0P7NMisp4OT8qi77IRDwnL3qVL3ZMI sWlWgnop9bg+N72l/7A8DscO4fx7EDviaydaI0RQNJtFYhj67I3L1kVzzsQ2/VHfPFLx KuWepHYOqVjMBtvAF9doDTQ8y82NoRdL85qdQjyg/SqoBofNGZ9fGFbml5dIBn+rjzMy AY++Melrt6mAKwAsGH2/bek34Nnbtwfm9iMXHzfKzIJ74oE++zaWTtYr3FPT9Qd+RHAH c84Tzz4xP39VS/bWB0dAiBRTzbuYifHGXxXaI4pPqv5d+BKbzxkmx9oSKfWtcCSnvKTT qzUA== X-Gm-Message-State: APjAAAVyLbO6Xi94Z8Z7weTCHn/4t3YjBrKdWRbUAtALveI1mPTCTlJ7 hnDzq8t3mMLEK2zazWolrbucS17q X-Google-Smtp-Source: APXvYqxnWWtfH67yizYG+cv2jPp0E2+kd+7c+S+CFCQAbXn1T7us1wRUezO8V4Y2yDn4+g6BWf83FQ== X-Received: by 2002:ae9:c10e:: with SMTP id z14mr930236qki.253.1575433357161; Tue, 03 Dec 2019 20:22:37 -0800 (PST) Received: from ?IPv6:2601:184:4180:66e7:c1ed:a694:851c:6c56? ([2601:184:4180:66e7:c1ed:a694:851c:6c56]) by smtp.googlemail.com with ESMTPSA id q35sm3199898qta.19.2019.12.03.20.22.35 for <bug-gnu-emacs@HIDDEN> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 03 Dec 2019 20:22:36 -0800 (PST) To: bug-gnu-emacs <bug-gnu-emacs@HIDDEN> From: =?UTF-8?Q?Cl=c3=a9ment_Pit-Claudel?= <cpitclaudel@HIDDEN> Subject: Customizing glyph widths Message-ID: <3183ba6c-6aea-fa25-bb32-7e5ff7c04ad6@HIDDEN> Date: Tue, 3 Dec 2019 23:22:35 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::730 X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.3 (--) Hi all, As recently discussed on emacs-devel (), it would be great to have a way to customize the way Emacs glyph widths. Here are the concrete use cases that I know of: * Ensuring that glyphs from variable-pitch fonts line up with monospace text. A common problem with prettify-symbols-mode is that the current programming font doesn't have all necessary symbols, so they get picked from a different (possibly non-monospace) font with a different character width, which breaks alignment. My current solution to this is to edit my font files directly (https://github.com/cpitclaudel/monospacifier). * Ensuring that wide characters, such as fullwidth CJK characters, properly line up with surrounding monospace text, my making them occupy the width of two spaces of the default font, rather than their own width (two spaces of their own font). One way to get the latter to work is to use composition to center each character over two spaces, but this is slow, inefficient, and it doesn't handle the former case where we sometimes want Emacs to fit a wider character into a narrower space. Interestingly, both of these cases are handled quite nicely in emacs -nw, because there the display is purely grid-like. I would like to have a way to do such grid-like display in graphical Emacs sessions as well, where each character occupies an exact multiple of the base character width, regardless of which font it comes from. As I wrote on emacs-devel "Deciding what this multiple should be for each character could be done in various ways; for my purposes (and for OP's case as well, I think), it would be enough to use one cell for halfwidth characters, two for fullwidth characters, and add a few exceptions for things like TAB and zero-width spaces (I'm using the terms fullwidth and halfwidth in the sense of https://www.unicode.org/reports/tr11/)." For my use case, it would be enough to have this available as a minor mode, but Yuan Fu mentioned the following on emacs-devel: "I’d like to see it as a face attribute instead of a mode. (Because I want to align my org table). Maybe there could be a face attribute (:grid WIDTH) that instructs the display engine to pad each glyph to have width that is a multiple of WIDTH in pixel, and if WIDTH is t, default to “base character width”? I remembered that ‘window-width’ gives width in char widths and had a look at its source. It knows the character width from FRAME_COLUMN_WIDTH; the comment says the value currently equals to the average width of the default font of the frame. I think this value can be used as the “base character width”." Now that I think of it, though, I could see the use for a text property. For example, prettify-symbols-mode could have an option to make each n-characters prettification n-characters wide, so that composing ~~> into ⟿ would produce a wide arrow occupying the exact same amount of space as the original uncomposed characters. One last note: one common complaint at the moment about prettify-symbols-mode is that it breaks indentation: if I prettify -> into →, the latter is one-character wide and thus any subsequent line that lines up with the → is one-character too far to the left when viewed without compositions (e.g. in a web browser). It would be wonderful if → could be centered into a two-spaced-wide cell and could count as occupying two columns (like TAB counts as occupying tab-width columns). Cheers, Clément.
Clément Pit-Claudel <cpitclaudel@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#38485; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.