GNU bug report logs -
#63861
[PATCH] pp.el: New "pretty printing" code
Previous Next
Full log
Message #17 received at 63861 <at> debbugs.gnu.org (full text, mbox):
[சனி ஜூன் 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.
This bug report was last modified 2 years and 27 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.