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

Previous Next

Full log

View this message in rfc822 format

From: Visuwesh <visuweshm <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 63861 <at> debbugs.gnu.org
Subject: bug#63861: [PATCH] pp.el: New "pretty printing" code
Date: Sun, 04 Jun 2023 08:55:29 +0530

[சனி ஜூன் 03, 2023] Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote:

> Hmm... so you think it should stay as a `defcustom` and we should thus
> plan to keep both kinds of pretty-printing in the long term?
> I mostly intended it to be a temporary knob for people to be able to try
> the new code and easily compare with the old (or revert to the old when
> bumping into a problem with the new).
>
> If so, we should probably think of better names to distinguish the two
> pp styles than `pp-buffer` vs `pp-region`.  Maybe `pp-fill` for the new
> code since arguably the main difference is that the new code pays
> attention to `fill-column`?  I don't have a good idea for a name for the
> old code, OTOH (and I think it would make sense to keep `pp-buffer` as
> a dispatch between the two options, so it would be good to have
> a separate name for the old style).
>
> Another difference might be that the new style is maybe aimed more at
> pp'ing code than data, whereas the old style might be a bit more
> "agnostic" to the definition.  Yet another difference is that the old
> code tends to use more lines (because it doesn't try to fill the line
> upto `fill-column`) and occasionally outputs very long lines because it
> only breaks lines near parentheses.

BTW, how does this compare to the newly added `pp-emacs-lisp-code'?
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.

Previous Next

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