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
