bug#63861: [PATCH] pp.el: New "pretty printing" code

[Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

>>> BTW, how does this compare to the newly added `pp-emacs-lisp-code`?
>> Very good question.  I had completely missed that (and its `pp-use-max-width`).
>> This points to a host of integration issues between my code and the
>> existing code.  I'll have to take a deeper look.
> From what I remember, pp simply switches to use pp-emacs-lisp-code when
> the relevant user option is set.

Yup, similar to my patch, except my patch hooks into `pp-buffer`,
i.e. a lower level which hence affects more uses.

> The poor performance of pp-emacs-lisp-code made me wish
> pp-use-max-width was only obeyed by user facing commands like
> pp-eval-expression & friends.

My tests yesterday suggest `pp-emacs-lisp-code` is simply too slow to be
used except when we know beforehand that the sexp to be printed
is small.  And I can't think of a single piece of code where that's
the case.  I suspect part of the code can be improved to bring the
computational complexity of the code closer to linear, but until
someone does that, I think `pp-use-max-width` is just unusable.
Instead we could/should provide ways for the user to interactively call
a command to reformat something using `pp-emacs-lisp-code`.  Or maybe
change the code so `pp-emacs-lisp-code` is used only when the total
printed size is below a certain threshold.

>> My new code is expected to be slower than the "normal" pretty-printer,
>> but barring performance bugs in `lisp-indent-line` (such as the one
>> fixed by the patch I just sent to Thierry) it should be approximately
>> a constant factor slower.
>> AFAICT the performance of `pp-emacs-lisp-code` can be more problematic.
> Hopefully, the constant factor is quite small.

In my tests, 10x seems to be the "worst case slowdown" of `pp-region`.
On some of the tests, it's actually faster, sometimes significantly so
(presumably due to some non-linear complexity in some parts of
`pp-buffer`).

> pp-emacs-lisp-code took a lot of time to print my modest bookmark
> alist (28 entries) and for the longest time I thought some other code
> in Emacs has gone awry.

AFAICT it suffers from a pretty bad complexity.

> I haven't tested your pretty printer but pp-emacs-lisp-code could give
> some really bizarre results for lisp data.

I haven't seen "really bizarre results" with `pp-region` yet, but
I wouldn't be surprised if that can happen: I've been playing with
various pretty-printing alternatives over the years and they all seem to
suffer from weird behaviors occasionally, except for those that insert
too many line breaks.


        Stefan