Nicolas Goaziou <> writes:

> Hello,
> Alex Branham <> writes:
>> But then users of global-prettify-symbols-mode don't see the pretty
>> symbols in org buffers without knowing about and activating
>> org-pretty-mode. Anyway, the attached patch moves it to org-pretty.el.
> [...]
>> I've left it as a defvar since there's no way for us to know about what
>> people want prettified where. Hopefully the default
>> prettify-symbols-compose-p function does an OK job, but people will have
>> to modify that if they customize org-pretty-alist anyway.
> I think there's a misunderstanding. To me, `prettify-symbols-mode' is
> the plumbing. Org Pretty users should not have to care about it.
> Likewise, when you use Org Bullets, you don't really care about how it
> is done internally.
> As such, we know what people want prettified if we provide the
> appropriate defcustom.
> BTW, the plumbing should be `compose-region', not
> `prettify-symbols-mode'.

IMO ‘prettify-symbols-mode’ is not pluming.  It’s an Emacs-wide equivalent
of "org-pretty-entities" (or at least the result when that variable is

IMO, the goal would be to offload more stuff into prettify-symbols-mode.
Since this involves a "regexp" in a sense, compose-region might be better.

In any case, the particular patch overwrites ‘prettify-symbols-alist’,
meaning which symbols will be displayed will depend on whether users have
their own pretty symbols loaded before the variable is being overwritten.


In theory, practice and theory are the same. In practice they are not

Reply via email to