GNU bug report logs - #63861
[PATCH] pp.el: New "pretty printing" code

Previous Next

Full log

Message #44 received at 63861 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Visuwesh <visuweshm <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 63861 <at> debbugs.gnu.org
Subject: Re: bug#63861: [PATCH] pp.el: New "pretty printing" code
Date: Wed, 07 Jun 2023 11:48:32 -0400

> 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.

> It was still rough around the edges the last time I set
> `pp-use-max-width' non-nil.  It is also quite a lot slower than the
> old path.

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.

Beside performance, I guess the behavior of the two should be
somewhat similar, tho I also see that `pp-emacs-lisp-code` pays
attention to the Edebug and `doc-string-elt` info, so it may give
slightly more refined info.

Another difference is that `pp-emacs-lisp-code` starts with an S-exp
object, whereas my code starts with a region (i.e. an sexp that's
already been printed).


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.