bug#38485: Customizing glyph widths

["Clément Pit-Claudel" <cpitclaudel@gmail.com>]

On 2019-12-04 12:05, Eli Zaretskii wrote:
>> Cc: 38485@debbugs.gnu.org
>> From: Clément Pit-Claudel <cpitclaudel@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.