Nicolas Goaziou <m...@nicolasgoaziou.fr> writes:

> Hello,
>
> Alex Branham <alex.bran...@gmail.com> 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
non-nil).

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.

Rasmus

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


Reply via email to