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

[D]

> 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.
> IOW, I think this solution is fragile.

In theory, yes. In practice this has (to my knowledge) not cropped up.
My approach is, however, a hack at the end of the day.  I mean, the
reason I acknowledge is that why I'm here :)

> And that's even before you consider
> complex text shaping which could combine several codepoints into a
> single wide grapheme cluster.

I don't think that using a character capable of that would be of any
use as a decorative element.  I'd say decorating a title or
representing an item bullet is largely the domain of dingbats,
geometric shapes, and to a lesser extent pictograms ("Emoji").

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

That would of course be the perfect solution.  But, doesn't this have
to exist in one way or another already?  For example, the checkbox
widget in custom interfaces to my knowledge visually replaces a simple
"[X]" with a bitmap.  When I examine a checkbox with C-u C-x = it
seems to be the case that display does the legwork and somehow obtains
the image size from the xpm file (I suppose).

(On an unrelated side note, I adore the custom interface.  Especially
the way you can specify complex composite types and tweak the
interface to be more expressive, and how you can safety check values
using :set)

> I suggest to try that and bring up any issues you
> have, then we could talk specifically about those issues.

Fair.

>> IIRC you can query Emacs about the size the character would have if it
>> were to be displayed right now in the currently selected window.
>> But you don't know that it's the same size as the character will have
>> when it will actually be displayed (and that char could have
>> simultaneously two different sizes in two different windows, of course).
>
> That's true, but for shr it doesn't (in general) make much difference.
> That is, if you display a rendered HTML document on two different
> displays, it'll look awful anyway, until you re-render tables and the
> like with the new width of the glyphs.  That is, a layout with
>
> | foo bar | more foo |
> | zot     |          |
>
> rarely looks on two different displays -- even if the :width/:align-to
> elements were to magically adjust themselves.

Same with superstar, essentially.  For example, every decorative
bullet can have a "fallback character" for terminal displays, and this
behaves correctly from the perspective of the frame you opened the
buffer with.  I include a simple redisplay command for emacsclient
users for this reason.  So I suppose I operate under the same
limitations as shr?

In that case, I probably should look into that character size
function.  Could you point me in the right general direction?  I'm not
quite sure how to find it.