bug#38485: Customizing glyph widths

[Eli Zaretskii]

> Cc: casouri@gmail.com, 38485@debbugs.gnu.org
> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Wed, 4 Dec 2019 13:14:19 -0500
> 
> >> 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?

No, it will simply make each prettified symbol take up the same width
as the original characters of the symbol that were composed.  Isn't
that what everyone would want, and want for _all_ prettified symbols?

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

I was talking about a variable that affects only results of character
compositions, so it won't affect a literal ⇒.  And another variable
will affect characters whose glyphs' width is different from an
integral multiple of the frame's default character's width.

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

Feel free.