bug#70868: 30.0.50;

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

>   M-: (pp-emacs-lisp-code '((quote a))) RET
>     => ('a)

Another one is nil vs. () or '() vs. 'nil, like in

  (defun f () ...)  vs.  (defun f nil ...)

or

  (delq nil my-list) vs. (delq () my-list)

etc, then - when to use dot syntax? - there is
`(foo . (,b)) vs. `(foo ,b) or

(let ((my-alist '((a . (1 2)) (b . (3 4))))) ...) vs.
(let ((my-alist '((a 1 2))    (b 3 4))) ...)

then (list +1 -1) vs. (list 1 -1), ?c vs. n vs ?\x... vs. ?\N...,
then there is "\n" vs "
" (docstrings!!!) - there is a ton of such ambiguities!

And note that we have only brought up silly one-line code examples so
far.  In real code, what the user expects will be _different_ for
different places in one and the same larger expression.

I totally agree that this problem is surprising and APITA, but please
don't expect that `pp-emacs-lisp-code' will ever produce satisfying
results when fed with existing code written by humans (i.e., when we
`read' and reprint it).  This will mess up as much as it prettifies, and
more.

And note there are even more problems of other kinds.  Another one is
that we don't discriminate context dependent semantics.  Is (let ...) a
`let' expression?  Or a `let' `pcase' form?  Or a list of names of
special forms?  Or maybe something which is meant to be macroexpanded to
a `let' expression, and the second element of the list is not a binding
list but something like ,(compute-let-bindings)?


I know these kinds of problems well and for years from my experience
with my "el-search" package - when I first tried an automatic rewriting
rule like

   `(if ,cond ,form) --> `(when ,cond ,form)

I was very disappointed about how ugly everything got when all in FORM
got folded to syntactical defaults.

[ For completion, if anyone wonders: in "el-search" I try to identify
the code parts that get part of the replacement expression - COND and
FORM in the above example - in the original code in the buffer operated
on and reuse the print syntax from there. ]


In sum I'm quite sure that

  M-: (pp--insert-lisp 'my-large-thunk-of-real-life-code)

is something that will never produce really good looking code whatever
guessing and heuristical cleverness we might be able to invent.  It will
always produce a result that a human will have to tune and correct
manually line by line.  Which is actually exactly the work we wanted to
delegate to this function!


So, my opinion is that Elisp pretty printing with input expressions, in
contrast to text, is, if at all, only useful for automatically generated
expressions (like macro expansions).  It's trivial that this will come
with the same problems (though in this case they are a bit less
surprising and annoying at least).  We should still fix this bug,
obviously.


Michael.