emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: prettify-symbols-mode, derived modes, and compose-region


From: Eli Zaretskii
Subject: Re: prettify-symbols-mode, derived modes, and compose-region
Date: Fri, 05 Mar 2021 09:08:35 +0200

> Cc: emacs-devel@gnu.org
> From: D <d.williams@posteo.net>
> Date: Fri, 5 Mar 2021 01:22:30 +0100
> 
> The data structure org-superstar-todo-bullet-alist associates a todo
> keyword with a character to be displayed.  The image shows the alignment
> problem.  The compose-region solution to this is simply to compose each
> character with a wide enough space, so the user simply has to use
> "\N{EM SPACE}<character>" instead of ?<character> in the alist.
> compose-region will then just superimpose the two and you get a "padded"
> character.

But how do you know that no character associated with a todo keyword
could ever be wider than the EM SPACE in the same font?  That's
entirely up to the font designer.  And that's even before you consider
complex text shaping which could combine several codepoints into a
single wide grapheme cluster.

IOW, I think this solution is fragile.

Anyway, I think it should be very easy to add a new display property
type that would override the pixel width of a font glyph with a fixed
value calculated in some way by a Lisp program.

> On a side note: Are there any quirks I should be aware of when
> transitioning to the display property? I doubt there will be any
> difference in terms of performance (contrast overlays, which my mode
> can't afford use), but is there anything else I should be aware of?  I'm
> asking in case there have been efforts like mine in the past which I am
> not aware of.

This question is too general, and the only answer I can give to such a
question is YES.  I suggest to try that and bring up any issues you
have, then we could talk specifically about those issues.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]