Re: Interface of prog-prettification

[Ted Zlatanov <tzz@lifelogs.com>]

On Sun, 16 Jun 2013 03:56:12 +0200 Juanma Barranquero <lekktu@gmail.com> wrote: 

JB> A few questions about the new prog-prettification.
JB> - prog--prettify-font-lock-compose-symbol's docstring says:
JB>   "Compose a sequence of ascii chars into a symbol."

JB> It is really true that it must be a sequence of ASCII characters? Why?

The original `perl-mode' implementation of the above said that.

JB> - Docstring of prog-prettify-symbols says:
JB>   "When set to an alist in the form `((STRING . CHARACTER)...)'"

JB> But in fact, instead of CHARACTER you can use a string, and its
JB> characters will be "composed" (stacked) together.

Yes.  Handa-san explained how composition works in that case and I
intend to document it, but it's neither explained nor supported right
now.  I think (as already suggested here) that an arbitrary string
should also be supported.

JB> - I don't fully understand how the user is supposed to extend the
JB> default modes' prog-prettification. What is the expected interface?

The user is not supposed to extend it.  I had that originally IIRC but
for simplicity we decided to make it one setting for all prog-modes.
The assumption is that if you like to prettify lambdas as symbols, you
won't mind it everywhere.

JB> Customizing prog-prettify-symbols sets the value for all prog-derived
JB> modes, but what if I want to use different prettifications for
JB> different modes?

JB> I tried adding (set (make-local-variable 'prog-prettify-symbols)
JB> '(("my-symbol" . ?MYCHAR))) to the relevant mode-hook, but that does
JB> not work.

Maybe a mode load hook call to `prog-prettify-install'?  I think
complicating the defcustom might be less user-friendly.  Suggestions
welcome.

JB> pushing '("my-symbol" . ?MYCHAR) to the corresponding mode-specific
JB> alist (lisp--prettify-symbols-alist,
JB> cfengine3--prettify-symbols-alist, perl--prettify-symbols-alist, etc.)
JB> works, but on one hand, these are internal, non-documented constants;
JB> on the other hand, that does not help to separate lisp-mode from
JB> emacs-lisp-mode, which are initialized from the same alist.

Right.  I think these complications, especially the inheritance aspect,
indicate it's better to let the user decide in the load hook than to try
to provide it in a more complicated data structure.

Ted