bug#29077: 26.0; NEWS: "Values in call stack frames are now displayed using `cl-prin1'"

[Noam Postavsky <npostavs@users.sourceforge.net>]

Drew Adams <drew.adams@oracle.com> writes:

> [Note: I could not send this from the Emacs 26 pretest, because of bug #29074.  I'm just mailing this in.]
>
> 1. The NEWS entry says only this (with British spelling, BTW):

The spelling was fixed in [1: def9715282].

>  The old behaviour of using 'prin1' can be restored by customizing the
>  new option 'debugger-print-function'.
>
> That doesn't tell a user how to restore the old behavior.  Please tell
> us what print function to use to get the old behavior.

Hmm, I feel that saying "The old behaviour of using 'prin1' can be
restored by customizing the new option 'debugger-print-function' to
'prin1'" is obvious and redundant to the point of condescension.

> The defcustom for `debugger-print-function' should offer a set of
> reasonable choices, plus let you specify an arbitrary function.  Those
> choices should include cl-prin1 and whatever the previously used print
> function was (what was it? clearly it was not `print').

Ah, I put :type 'function and :options '(cl-prin1 prin1), but apparently
this doesn't actually have any effect in the customize buffer.  Do you
know how to fix this?

> 2. Also, the function used is apparently really `cl-prin1', and there is NO doc for that function.  C-h f cl-prin1 shows this:
>
>   cl-prin1 is an autoloaded Lisp closure in `cl-print.el'.
>
>   (cl-prin1 OBJECT &optional STREAM)
>
>   Not documented.
>
> That's another bug, but please fix it as part of this report.

It was fixed about a month ago [2: 8130186cfb].

> 3. Also, is the backtrace really printed using prin1 or cl-prin1? I
> have print-length and print-level set to nil and print-circle set to t
> or nil (neither helps).  I turn off truncated lines.  And yet for a
> return value that is a list of 57 elements in *Backtrace* I cannot
> move to the end of the list - the displayed list is truncated after a
> bit.
>
> That's useless.  Users should be able to get a full *Backtrace*, being able to move over full Lisp objects such as lists.
>
> I don't see this problem in previous Emacs releases.

Hmm, works for me.  I tried

(defun return-a-long-list ()
  (number-sequence 1 100))

M-x debug-on-entry RET return-a-long-list RET
M-: (return-a-long-list) RET

And I could see the whole thing just fine.

> This "feature" (of cl-prin1 or whatever) has apparently not been
> road-tested.  Please revert it as the default behavior.  Let users opt
> in to use it, until you get it to work.  It's generally a bad idea to
> change the default behavior to some new, untested behavior.  Let users
> try it out for a few releases, before deciding to make it the new
> default behavior.

But then how would we get it road-tested by pretesters such as yourself?
:)

We could turn it back for 26.1 still, I guess the maintainers should
make this call.

[1: def9715282]: 2017-10-14 12:52:05 +0200
  ; Cleanup of etc/NEWS
  https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=def9715282f71953740e8b92cf6443bfc459dd41
  
[2: 8130186cfb]: 2017-09-11 22:16:14 -0400
  Add docstrings to cl-print entry points
  https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=8130186cfb830d82e7d0cc6fb7443e3b6e026660