[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: prettify-symbols-mode, derived modes, and compose-region
From: |
Eli Zaretskii |
Subject: |
Re: prettify-symbols-mode, derived modes, and compose-region |
Date: |
Thu, 04 Mar 2021 23:54:10 +0200 |
> 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.
- prettify-symbols-mode, derived modes, and compose-region, D, 2021/03/04
- Re: prettify-symbols-mode, derived modes, and compose-region,
Eli Zaretskii <=
- Re: prettify-symbols-mode, derived modes, and compose-region, D, 2021/03/04
- Re: prettify-symbols-mode, derived modes, and compose-region, Stefan Monnier, 2021/03/04
- Re: prettify-symbols-mode, derived modes, and compose-region, Stefan Kangas, 2021/03/04
- Re: prettify-symbols-mode, derived modes, and compose-region, Eli Zaretskii, 2021/03/05
- Re: prettify-symbols-mode, derived modes, and compose-region, Eli Zaretskii, 2021/03/05
- Re: prettify-symbols-mode, derived modes, and compose-region, Stefan Monnier, 2021/03/05
- Re: prettify-symbols-mode, derived modes, and compose-region, Eli Zaretskii, 2021/03/05
- Re: prettify-symbols-mode, derived modes, and compose-region, Stefan Monnier, 2021/03/05
- Re: prettify-symbols-mode, derived modes, and compose-region, Lars Ingebrigtsen, 2021/03/05
- Re: prettify-symbols-mode, derived modes, and compose-region, Eli Zaretskii, 2021/03/05