GNU bug report logs - #38485
Customizing glyph widths

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: emacs; Reported by: Clément Pit-Claudel <cpitclaudel@HIDDEN>; dated Wed, 4 Dec 2019 04:24:01 UTC; Maintainer for emacs is bug-gnu-emacs@HIDDEN.

Message received at 38485 <at> debbugs.gnu.org:


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.)





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#38485; Package emacs. Full text available.

Message received at 38485 <at> debbugs.gnu.org:


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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#38485; Package emacs. Full text available.

Message received at 38485 <at> debbugs.gnu.org:


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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#38485; Package emacs. Full text available.

Message received at submit <at> debbugs.gnu.org:


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.




Acknowledgement sent to Clément Pit-Claudel <cpitclaudel@HIDDEN>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs@HIDDEN. Full text available.
Report forwarded to bug-gnu-emacs@HIDDEN:
bug#38485; Package emacs. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Wed, 4 Dec 2019 17:15:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.