GNU bug report logs -
#38485
Customizing glyph widths
Previous Next
Full log
Message #17 received at 38485 <at> debbugs.gnu.org (full text, mbox):
On 2019-12-04 12:05, Eli Zaretskii wrote:
>> Cc: 38485 <at> debbugs.gnu.org
>> From: Clément Pit-Claudel <cpitclaudel <at> gmail.com>
>> 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.
Would this buffer-local variable be an alist mapping each character to the desired width? If so, this could cause issues with alignment. Consider the following:
(fun x => 1 +
x + x)
This currently gets prettified like this:
(fun x ⇒ 1 +
x + x)
and then reindenting yields this:
(fun x ⇒ 1 +
x + x)
which looks wrong when viewed outside of Emacs:
(fun x => 1 +
x + x)
If prettify-symbols could tell Emacs to center ⇒ into a two-spaces-wide stretch, things would indent and look good in both cases. This is how fonts like Fira code handle the alignment problem (the ⇒ ligature in Fira code is two-characters wide).
However, consider this instead:
(fun x ⇒ 1 +
x + x)
In this example the user worte an actual '⇒' in the buffer. In that case, it shouldn't be widened to two characters, otherwise indentation will look broken.
>> 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.)
Should I open a separate request? I get the sense that it won't make much sense until we implement this one (if we do), so maybe I'll wait.
Clément.
This bug report was last modified 5 years and 195 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.