[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#29077: 26.0; NEWS: "Values in call stack frames are now displayed us
From: |
Noam Postavsky |
Subject: |
bug#29077: 26.0; NEWS: "Values in call stack frames are now displayed using `cl-prin1'" |
Date: |
Mon, 30 Oct 2017 19:27:45 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (gnu/linux) |
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