[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#63861: [PATCH] pp.el: New "pretty printing" code
From: |
Stefan Monnier |
Subject: |
bug#63861: [PATCH] pp.el: New "pretty printing" code |
Date: |
Fri, 09 Jun 2023 10:59:18 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
>>> 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
- bug#63861: [PATCH] pp.el: New "pretty printing" code, Stefan Monnier, 2023/06/02
- bug#63861: [PATCH] pp.el: New "pretty printing" code, Eli Zaretskii, 2023/06/03
- bug#63861: [PATCH] pp.el: New "pretty printing" code, Stefan Monnier, 2023/06/03
- bug#63861: [PATCH] pp.el: New "pretty printing" code, Eli Zaretskii, 2023/06/03
- bug#63861: [PATCH] pp.el: New "pretty printing" code, Visuwesh, 2023/06/03
- bug#63861: [PATCH] pp.el: New "pretty printing" code, Stefan Monnier, 2023/06/07
- bug#63861: [PATCH] pp.el: New "pretty printing" code, Visuwesh, 2023/06/08
- bug#63861: [PATCH] pp.el: New "pretty printing" code,
Stefan Monnier <=
- bug#63861: [PATCH] pp.el: New "pretty printing" code, Ihor Radchenko, 2023/06/09
- bug#63861: [PATCH] pp.el: New "pretty printing" code, Stefan Monnier, 2023/06/09
- bug#63861: [PATCH] pp.el: New "pretty printing" code, Visuwesh, 2023/06/09
- bug#63861: [PATCH] pp.el: New "pretty printing" code, Visuwesh, 2023/06/09
- bug#63861: [PATCH] pp.el: New "pretty printing" code, Juri Linkov, 2023/06/05
- bug#63861: [PATCH] pp.el: New "pretty printing" code, Stefan Monnier, 2023/06/07
- bug#63861: [PATCH] pp.el: New "pretty printing" code, Juri Linkov, 2023/06/07
- bug#63861: [PATCH] pp.el: New "pretty printing" code, Stefan Monnier, 2023/06/07
bug#63861: [PATCH] pp.el: New "pretty printing" code, Thierry Volpiatto, 2023/06/07