unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* prettify-symbols-mode, derived modes, and compose-region
@ 2021-03-04 21:33 D
  2021-03-04 21:54 ` Eli Zaretskii
  0 siblings, 1 reply; 17+ messages in thread
From: D @ 2021-03-04 21:33 UTC (permalink / raw)
  To: emacs-devel

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




^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2021-03-06 10:59 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-03-04 21:33 prettify-symbols-mode, derived modes, and compose-region D
2021-03-04 21:54 ` 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

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).