GNU logs - #38485, boring messages

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#38485: Customizing glyph widths
Resent-From: =?UTF-8?Q?Cl=C3=A9ment?= Pit-Claudel <cpitclaudel@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 04 Dec 2019 04:24:01 +0000
Resent-Message-ID: <handler.38485.B.15754333853382 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 38485 <at> debbugs.gnu.org
From: =?UTF-8?Q?Cl=C3=A9ment?= Pit-Claudel <cpitclaudel@HIDDEN>
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
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

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.

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: =?UTF-8?Q?Cl=C3=A9ment?= Pit-Claudel <cpitclaudel@HIDDEN>
Subject: bug#38485: Acknowledgement (Customizing glyph widths)
Message-ID: <handler.38485.B.15754333853382.ack <at> debbugs.gnu.org>
References: <3183ba6c-6aea-fa25-bb32-7e5ff7c04ad6@HIDDEN>
X-Gnu-PR-Message: ack 38485
X-Gnu-PR-Package: emacs
Reply-To: 38485 <at> debbugs.gnu.org
Date: Wed, 04 Dec 2019 04:24:01 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 38485 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
38485: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D38485
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#38485: Customizing glyph widths
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 04 Dec 2019 15:53:01 +0000
Resent-Message-ID: <handler.38485.B38485.157547474818060 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: =?UTF-8?Q?Cl=C3=A9ment?= Pit-Claudel <cpitclaudel@HIDDEN>, Yuan Fu <casouri@HIDDEN>
Cc: 38485 <at> debbugs.gnu.org
Date: Wed, 04 Dec 2019 17:52:12 +0200
Message-Id: <83y2vshyvn.fsf@HIDDEN>
From: Eli Zaretskii <eliz@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)
References: <3183ba6c-6aea-fa25-bb32-7e5ff7c04ad6@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

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

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#38485: Customizing glyph widths
Resent-From: =?UTF-8?Q?Cl=C3=A9ment?= Pit-Claudel <cpitclaudel@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 04 Dec 2019 16:58:01 +0000
Resent-Message-ID: <handler.38485.B38485.157547864231779 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Eli Zaretskii <eliz@HIDDEN>, Yuan Fu <casouri@HIDDEN>
Cc: 38485 <at> debbugs.gnu.org
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
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

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.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#38485: Customizing glyph widths
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 04 Dec 2019 17:06:02 +0000
Resent-Message-ID: <handler.38485.B38485.157547913332671 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 38485
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: =?UTF-8?Q?Cl=C3=A9ment?= Pit-Claudel <cpitclaudel@HIDDEN>
Cc: casouri@HIDDEN, 38485 <at> debbugs.gnu.org
Received: via spool by 38485-submit <at> debbugs.gnu.org id=B38485.157547913332671
          (code B ref 38485); Wed, 04 Dec 2019 17:06:02 +0000
Received: (at 38485) by debbugs.gnu.org; 4 Dec 2019 17:05:33 +0000
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>
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)
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-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.)

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.