From: D <d.williams@posteo.net>
To: emacs-devel@gnu.org
Subject: prettify-symbols-mode, derived modes, and compose-region
Date: Thu, 4 Mar 2021 22:33:01 +0100 [thread overview]
Message-ID: <eced92df-4bf6-316d-b041-b7bae23dd609@posteo.net> (raw)
Hello,
I would like to ask what the general consensus is regarding the way
prettify-symbols-mode (and similar modes) work, given my current use
case. For context, I am the developer and maintainer of
org-superstar-mode[1], a purely cosmetic minor mode for Org. It
serves as a "spiritual successor" to the popular org-bullets[2] (of
which I maintain the form used for MELPA[3]). Both of these minor
modes (ab)use static character composition to achieve their visual
effect, instead of utilizing the display text property. Recently, the
following comment has been brought to my attention on this subject
recently[4] (by a user named eli-zaretskii):
> 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? 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).
Kind regards,
D.
Footnotes:
[1] https://github.com/integral-dw/org-superstar-mode
[2] https://github.com/sabof/org-bullets
[3] https://github.com/integral-dw/org-bullets
[4]
https://www.reddit.com/r/emacs/comments/brt0sk/prettifysymbolsmode_is_so_cool/eomb5av?utm_source=share&utm_medium=web2x&context=3
next reply other threads:[~2021-03-04 21:33 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-04 21:33 D [this message]
2021-03-04 21:54 ` prettify-symbols-mode, derived modes, and compose-region Eli Zaretskii
2021-03-05 0:22 ` D
2021-03-05 2:30 ` Stefan Monnier
2021-03-05 3:20 ` Stefan Kangas
2021-03-05 7:25 ` Eli Zaretskii
2021-03-05 7:18 ` Eli Zaretskii
2021-03-05 15:14 ` Stefan Monnier
2021-03-05 15:20 ` Eli Zaretskii
2021-03-05 15:51 ` Stefan Monnier
2021-03-05 15:57 ` Lars Ingebrigtsen
2021-03-05 7:08 ` Eli Zaretskii
2021-03-05 14:05 ` Clément Pit-Claudel
2021-03-05 21:24 ` D
2021-03-06 9:15 ` Eli Zaretskii
2021-03-06 10:43 ` D
2021-03-06 10:59 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=eced92df-4bf6-316d-b041-b7bae23dd609@posteo.net \
--to=d.williams@posteo.net \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.