From: Eli Zaretskii <eliz@gnu.org>
To: D <d.williams@posteo.net>
Cc: emacs-devel@gnu.org
Subject: Re: prettify-symbols-mode, derived modes, and compose-region
Date: Thu, 04 Mar 2021 23:54:10 +0200 [thread overview]
Message-ID: <83k0qmzit9.fsf@gnu.org> (raw)
In-Reply-To: <eced92df-4bf6-316d-b041-b7bae23dd609@posteo.net> (message from D on Thu, 4 Mar 2021 22:33:01 +0100)
> 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.
next prev parent reply other threads:[~2021-03-04 21:54 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-04 21:33 prettify-symbols-mode, derived modes, and compose-region D
2021-03-04 21:54 ` Eli Zaretskii [this message]
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=83k0qmzit9.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=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.