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

[Visuwesh <visuweshm@gmail.com>]

[சனி ஜூன் 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.