bug#38485: Customizing glyph widths

bug#38485: Customizing glyph widths

[Clément Pit-Claudel]

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.

bug#38485: Customizing glyph widths

[Eli Zaretskii]

> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> 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.

bug#38485: Customizing glyph widths

[Clément Pit-Claudel]

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.

bug#38485: Customizing glyph widths

[Eli Zaretskii]

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

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

bug#38485: Customizing glyph widths

[Clément Pit-Claudel]

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.

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.

bug#38485: Customizing glyph widths

[Clément Pit-Claudel]

On 2019-12-04 13:45, Eli Zaretskii wrote:
>> 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?

Probably not.  In proof-general, we display 'forall' as ∀ and 'exists' as ∃.  In my own configuration I also change "Qed" to ■ "Defined" to □, and "Admitted" to 😱.  These shouldn't be widened, I think — especially not the last ones (there is a case to be made for widening forall, since otherwise we might get indentation issues, but in Coq Qed, Defined and Admitted don't introduce indentation changes, so it's safe not to widen them.

Clément.

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 15:53:43 -0500
> 
> > 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?
> 
> Probably not.  In proof-general, we display 'forall' as ∀ and 'exists' as ∃.  In my own configuration I also change "Qed" to ■ "Defined" to □, and "Admitted" to 😱.  These shouldn't be widened, I think — especially not the last ones (there is a case to be made for widening forall, since otherwise we might get indentation issues, but in Coq Qed, Defined and Admitted don't introduce indentation changes, so it's safe not to widen them.

Are you saying that we _can_ not widen them, or are you saying that we
_must_not_ widen them?  If the latter, can you explain why not?

bug#38485: Customizing glyph widths

[Clément Pit-Claudel]

On 2019-12-04 22:34, Eli Zaretskii wrote:
>> Cc: casouri@gmail.com, 38485@debbugs.gnu.org
>> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
>> Date: Wed, 4 Dec 2019 15:53:43 -0500
>>
>>> 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?
>>
>> Probably not.  In proof-general, we display 'forall' as ∀ and 'exists' as ∃.  In my own configuration I also change "Qed" to ■ "Defined" to □, and "Admitted" to 😱.  These shouldn't be widened, I think — especially not the last ones (there is a case to be made for widening forall, since otherwise we might get indentation issues, but in Coq Qed, Defined and Admitted don't introduce indentation changes, so it's safe not to widen them.
> 
> Are you saying that we _can_ not widen them, or are you saying that we
> _must_not_ widen them?  If the latter, can you explain why not?

That we must not.  I set up these prettifications specifically to make the characters narrower and reduce visual clutter; widening them would defeat that purpose.

I commonly write things like this:

  Lemma lcomm: forall x y, x ~+~ y <-> y ~+~ x.
  Proof. induction x; cbn; try rewrite IHx; reflexivity. Defined.

with prettification, it looks like this:

  Lemma lcomm: ∀ x y, x ⨤ y ↔ y ⨤ x.
  ∵. induction x; cbn; try rewrite IHx; reflexivity. □.

What I really want is this:

  Lemma lcomm: ∀ x y, x  ⨤  y  ↔  y  ⨤  x.
  ∵. induction x; cbn; try rewrite IHx; reflexivity. □.

but not this:

  Lemma lcomm: ∀      x y, x  ⨤  y  ↔  y  ⨤  x.
  ∵    . induction x; cbn; try rewrite IHx; reflexivity. □      .

Clément.

bug#38485: Customizing glyph widths

[Eli Zaretskii]

> Cc: casouri@gmail.com, 38485@debbugs.gnu.org
> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Thu, 5 Dec 2019 09:26:12 -0500
> 
> > Are you saying that we _can_ not widen them, or are you saying that we
> > _must_not_ widen them?  If the latter, can you explain why not?
> 
> That we must not.  I set up these prettifications specifically to make the characters narrower and reduce visual clutter; widening them would defeat that purpose.

So in this case the alignment considerations are thrown out the
window?

> I commonly write things like this:
> 
>   Lemma lcomm: forall x y, x ~+~ y <-> y ~+~ x.
>   Proof. induction x; cbn; try rewrite IHx; reflexivity. Defined.
> 
> with prettification, it looks like this:
> 
>   Lemma lcomm: ∀ x y, x ⨤ y ↔ y ⨤ x.
>   ∵. induction x; cbn; try rewrite IHx; reflexivity. □.
> 
> What I really want is this:
> 
>   Lemma lcomm: ∀ x y, x  ⨤  y  ↔  y  ⨤  x.
>   ∵. induction x; cbn; try rewrite IHx; reflexivity. □.
> 
> but not this:
> 
>   Lemma lcomm: ∀      x y, x  ⨤  y  ↔  y  ⨤  x.
>   ∵    . induction x; cbn; try rewrite IHx; reflexivity. □      .

Why is "Proof" treated differently from the other symbols?  How would
the user know which one is which?

bug#38485: Customizing glyph widths

[Clément Pit-Claudel]

On 2019-12-05 10:19, Eli Zaretskii wrote:
>> Cc: casouri@gmail.com, 38485@debbugs.gnu.org
>> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
>> Date: Thu, 5 Dec 2019 09:26:12 -0500
>>
>>> Are you saying that we _can_ not widen them, or are you saying that we
>>> _must_not_ widen them?  If the latter, can you explain why not?
>>
>> That we must not.  I set up these prettifications specifically to make the characters narrower and reduce visual clutter; widening them would defeat that purpose.
> 
> So in this case the alignment considerations are thrown out the
> window?

Yes; for 'forall' it's debatable, but for Qed, Defined and Admitted it's safe to not widen them, because they don't introduce indentation points.

>> I commonly write things like this:
>>
>>   Lemma lcomm: forall x y, x ~+~ y <-> y ~+~ x.
>>   Proof. induction x; cbn; try rewrite IHx; reflexivity. Defined.
>>
>> with prettification, it looks like this:
>>
>>   Lemma lcomm: ∀ x y, x ⨤ y ↔ y ⨤ x.
>>   ∵. induction x; cbn; try rewrite IHx; reflexivity. □.
>>
>> What I really want is this:
>>
>>   Lemma lcomm: ∀ x y, x  ⨤  y  ↔  y  ⨤  x.
>>   ∵. induction x; cbn; try rewrite IHx; reflexivity. □.
>>
>> but not this:
>>
>>   Lemma lcomm: ∀      x y, x  ⨤  y  ↔  y  ⨤  x.
>>   ∵    . induction x; cbn; try rewrite IHx; reflexivity. □      .
> 
> Why is "Proof" treated differently from the other symbols?  How would
> the user know which one is which?

Sorry, I think I don't understand the question :/

bug#38485: Customizing glyph widths

[Eli Zaretskii]

> Cc: casouri@gmail.com, 38485@debbugs.gnu.org
> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Thu, 5 Dec 2019 14:50:54 -0500
> 
> > Why is "Proof" treated differently from the other symbols?  How would
> > the user know which one is which?
> 
> Sorry, I think I don't understand the question :/

Which part?

You have shown an example where some prettified symbols are treated
differently than others, with respect to their width on display.  I'm
asking why the difference, and how will users know when to ask one
behavior and when the other.

bug#38485: Customizing glyph widths

[Clément Pit-Claudel]

On 2019-12-05 15:06, Eli Zaretskii wrote:
>> Cc: casouri@gmail.com, 38485@debbugs.gnu.org
>> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
>> Date: Thu, 5 Dec 2019 14:50:54 -0500
>>
>>> Why is "Proof" treated differently from the other symbols?  How would
>>> the user know which one is which?
>>
>> Sorry, I think I don't understand the question :/
> 
> Which part?
> 
> You have shown an example where some prettified symbols are treated
> differently than others, with respect to their width on display.  I'm
> asking why the difference, and how will users know when to ask one
> behavior and when the other.

Thanks, it's clear now.

This is something I'd like to be able to customize for each symbol.
That is, I'd like to be able to say that "forall" should be prettified as "∀", taking one character, and that "~+~" should be prettified as "⨤", taking three characters.
In Elisp, I'd like to say that prettifications from nameless-mode shouldn't be widened, nor lambda.

I expect which behavior to pick will be a matter of preference.  What I do currently in my Emacs is to narrow all characters to one character, by recompiling various fonts to have the right width, but that isn't pleasant.

bug#38485: "prettified" symbols

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Would someone please send me a 10-line general explanation of
what the "prettified" symbols feature does, or would do?

In what modes or contexts would this operate, by default?

-- 
Dr Richard Stallman
Founder, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#38485: "prettified" symbols

[Clément Pit-Claudel]

On 2019-12-05 23:15, Richard Stallman wrote:
> Would someone please send me a 10-line general explanation of
> what the "prettified" symbols feature does, or would do?>
> In what modes or contexts would this operate, by default?

Happy to oblige :)

prettified-symbols-mode is a minor mode that appeared around Emacs 24.5 or so, a few years ago.  It lets users instruct Emacs to change the way certain words or symbols are displayed, to make the contents of the buffer more visually appealing or easier to read.  It doesn't change the actual contents of the buffer, nor what gets saved to disk.

For example, consider the following bits of C and C++ code:

  pstr->wcs[idx] != WEOF || pstr->valid_len == idx + 1
  std::cout << (x >= 0);

If I set prettify-symbols-alist to the following value:

  (setq-local prettify-symbols-alist
              '(("->" . ?→) ("!=" . ?≠) ("==" . ?≡)
                (">=" . ?≥) ("||" . ?‖) ("::" . ?∷)
                ("<<" . ?≪)))

then Emacs will display these snippets thus:

  pstr→wcs[idx] ≠ WEOF ‖ pstr→valid_len ≡ idx + 1
  std∷cout ≪ (x ≥ 0);

I don't think this feature is enabled by default in any mode that ships with Emacs, but it is in some third-party packages.  It is particularly popular for users of math-oriented programming languages; for example, this is the value of prettify-symbols-alist in fstar-mode:

  '(("exists" . ?∃) ("forall" . ?∀) ("fun" . ?λ)
    ("nat" . ?ℕ) ("int" . ?ℤ)
    ("True" . ?⊤) ("False" . ?⊥)
    ("*" . ?×) (":=" . ?≔) ("::" . ?⸬)
    ("<=" . ?≤) (">=" . ?≥) ("<>" . ?≠)
    ("/\\" . ?∧) ("\\/" . ?∨) ("~" . ?¬) ("||" . ?‖)
    ("<==>" . ?⟺) ("==>" . ?⟹) ;; ("<==" . ?⟸)
    ("->" . ?→) ("~>" . ?↝) ("=>" . ?⇒)
    ("<-" . ?←) ("<--" . ?⟵) ("-->" . ?⟶)
    ("<<" . ?≪) ("<|" . ?◃) ("|>" . ?▹)
    ("'a" . ?α) ("'b" . ?β) ("'c" . ?γ)
    ("'d" . ?δ) ("'e" . ?ε) ("'f" . ?φ)
    ("'g" . ?χ) ("'h" . ?η) ("'i" . ?ι)
    ("'k" . ?κ) ("'m" . ?μ) ("'n" . ?ν)
    ("'p" . ?π) ("'q" . ?θ) ("'r" . ?ρ)
    ("'s" . ?σ) ("'t" . ?τ) ("'u" . ?ψ)
    ("'w" . ?ω) ("'x" . ?ξ) ("'z" . ?ζ))

You should try it :) It's packaged with Emacs, and it's a really neat feature.

Clément.

bug#38485: "prettified" symbols

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: eliz@gnu.org, casouri@gmail.com, 38485@debbugs.gnu.org
> Date: Thu, 05 Dec 2019 23:15:27 -0500
> 
> Would someone please send me a 10-line general explanation of
> what the "prettified" symbols feature does, or would do?

It displays symbol names in programming languages as pretty symbols.
For example, "lambda" in Lisp can be displayed as λ.  This uses static
character composition to do its job.

I suggest to look at the code, it's quite short and simple.  Start
around line 200 in prog-mode.el, where prettify-symbols-mode is
defined.

> In what modes or contexts would this operate, by default?

By default, this mode is turned off.  You need to turn it on, and it
is currently written to work with programming-language major modes.

bug#38485: "prettified" symbols

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > It displays symbol names in programming languages as pretty symbols.
  > For example, "lambda" in Lisp can be displayed as λ.  This uses static
  > character composition to do its job.

It sounds like something that might perhaps help with reading a
program, but wouldn't it make editing confusing?  'lambda' is 6
characters; making it appear as one character has to mess something
up.

As long as it is disabled by default, I don't see a problem in having
the feature.

-- 
Dr Richard Stallman
Founder, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#38485: Customizing glyph widths

[Clément Pit-Claudel]

On 2019-12-04 13:45, Eli Zaretskii wrote:
>> 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?

Another example: the nameless-mode pacakge uses prettification to display the name of the current file as :, so that in foo-bar.el the symbol foo-bar-xyz displays as :xyz (with a different color for the colon) to shorten lines and improve readability.  Widening this ':' would defeat the purpose of that package.

Clément.

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 15:55:38 -0500
> 
> Another example: the nameless-mode pacakge uses prettification to display the name of the current file as :, so that in foo-bar.el the symbol foo-bar-xyz displays as :xyz (with a different color for the colon) to shorten lines and improve readability.  Widening this ':' would defeat the purpose of that package.

That's why I suggest a buffer-local variable.  This package should not
set it, then.

And anyway, trying to lump too many conflicting requirements is likely
to have only one result: that this will never get implemented.

bug#38485: Customizing glyph widths

[Clément Pit-Claudel]

On 2019-12-04 22:36, Eli Zaretskii wrote:
>> Cc: casouri@gmail.com, 38485@debbugs.gnu.org
>> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
>> Date: Wed, 4 Dec 2019 15:55:38 -0500
>>
>> Another example: the nameless-mode pacakge uses prettification to display the name of the current file as :, so that in foo-bar.el the symbol foo-bar-xyz displays as :xyz (with a different color for the colon) to shorten lines and improve readability.  Widening this ':' would defeat the purpose of that package.
> 
> That's why I suggest a buffer-local variable.  This package should not
> set it, then.

But you could mix this package with other prettifications, and want the widening behavior for these prettifications but not the nameless-mode ones.


Here's another example: When I write (lambda x (+ x x)) in Elisp and it gets abbreviated to (λ x (+ x x)), I wouldn't want it to be changed to (λ     x (+ x x)).  
But if I write this:

  (-> lst
      sort
      nreverse)

Then I do want it to be prettified to

  (→  lst
      sort
      nreverse)

and not to

  (→ lst
      sort
      nreverse)

Clément.

bug#38485: Customizing glyph widths

[Yuan Fu]

[-- Attachment #1: Type: text/plain, Size: 993 bytes --]


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

What Clément want and what I want are not quite similar. For my purpose, I want my text tables in org mode to be aligned even there is Chinese characters in it. For example, with out alignment (in GUI):



With alignment (in terminal):


However, I generally use variable-pitch everywhere else in a Org file. Because variable-pitch are generally prettier.

> Using a face also means that the same characters from a larger font
> will not be aligned.

For me personally, that’s ok. I can just use a smaller font.


But again, I just want to know if such a feature exists or is easily hackable. If not, I can live without it. Clément’s idea seems doable, though. You just need a local variable that maps glyph’s unicode to the intended width, if I understand him correctly.

Yuan


[-- Attachment #2.1: Type: text/html, Size: 5373 bytes --]

[-- Attachment #2.2: Screen Shot 2019-12-04 at 10.17.47 PM.png --]
[-- Type: image/png, Size: 10699 bytes --]

[-- Attachment #2.3: Screen Shot 2019-12-04 at 10.18.37 PM.png --]
[-- Type: image/png, Size: 10849 bytes --]