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

[Eli Zaretskii <eliz@gnu.org>]

> From: D <d.williams@posteo.net>
> Date: Thu, 4 Mar 2021 22:33:01 +0100
> 
> > I'm sorry, but I don't share your enthusiasm about
> > prettify-symbols-mode. It piggy-backs a feature, called "static
> > character composition", which was never designed for this job, and
> > which is nowadays rarely if ever used for the job it was designed
> > for. So it has bit-rotted, and in some not-too-far future we will
> > probably want to obsolete and remove the static character composition
> > from Emacs, at which point prettify-symbols-mode will be a huge drag.
> 
> I empathize with the sentiment, which consequently brings me here to
> ask: Should I consider relying on composition "future-proof" or is
> this use discouraged?

Yes, I'd very much like to discourage the use of static compositions.
Especially in text-related modes such as Org, where human-readable
text is the main content (as opposed to programming-language modes).
That's because static compositions don't support bidirectional editing
and display, and so some of the scripts and languages we support
elsewhere in Emacs are off-limits when static compositions are
involved.  So prettify-symbols-mode is semi-okay, as it is usually
turned on in PL modes, where everything is left-to-right.  But using
the same techniques in Org is from my POV much worse, and I'd be
happier if that could be avoided.

> Because if it is, I may run into an issue.  In
> the case of org-bullets, I have no qualms to just rid the code of the
> composition hack, as it (to my knowledge) serves no purpose there that
> can't trivially be fulfilled by the display property.  Meanwhile,
> Superstar has a more "justified" reason to favor composition over
> display: The decorations it adds to a buffer are not necessarily
> monospaced in a given user's font set.  This can lead to alignment
> problems for entries that should be the same level of indentation.
> Superstar solves this problem by letting the user superimpose the
> decoration character with whitespace.  This way, a user can have an
> asterisk display as a <too-thin-char> while keeping alignment by using
> the string "\s<too-thin-char>", which is passed to compose-region and
> produces the desired result.  Conversely, too wide chars can be
> "normalized" by using U2003 (EM SPACE) and similar characters to widen
> all affected "bullets" equally.  If static composition were to be
> deprecated, I would not be able to provide this feature anymore, and
> it's the primary reason I don't think I could avoid the composition
> hack in Superstar (given it directly benefits from actual
> composition).

I'm not sure I understand the problem, but can't you use :align-to in
display properties to solve the alignment issues?

Thanks.