* bug#29077: 26.0; NEWS: "Values in call stack frames are now displayed using `cl-prin1'"
@ 2017-10-30 22:18 Drew Adams
2017-10-30 23:27 ` Noam Postavsky
0 siblings, 1 reply; 6+ messages in thread
From: Drew Adams @ 2017-10-30 22:18 UTC (permalink / raw)
To: 29077
[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 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.
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').
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.
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.
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#29077: 26.0; NEWS: "Values in call stack frames are now displayed using `cl-prin1'"
2017-10-30 22:18 bug#29077: 26.0; NEWS: "Values in call stack frames are now displayed using `cl-prin1'" Drew Adams
@ 2017-10-30 23:27 ` Noam Postavsky
2017-10-31 16:41 ` Drew Adams
0 siblings, 1 reply; 6+ messages in thread
From: Noam Postavsky @ 2017-10-30 23:27 UTC (permalink / raw)
To: Drew Adams; +Cc: 29077
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#29077: 26.0; NEWS: "Values in call stack frames are now displayed using `cl-prin1'"
2017-10-30 23:27 ` Noam Postavsky
@ 2017-10-31 16:41 ` Drew Adams
2017-10-31 22:56 ` Noam Postavsky
0 siblings, 1 reply; 6+ messages in thread
From: Drew Adams @ 2017-10-31 16:41 UTC (permalink / raw)
To: Noam Postavsky; +Cc: 29077
> > 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.
My bad; sorry. I misread it as saying that the new behavior
is to use `prin1'. I guess I didn't notice the difference
between `prin1' and `cl-prin1'. User error - no problem to
fix, here.
> > 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?
Not really. Maybe there is no good solution. As (elisp) node
`Variable Definitions' says about `:options':
This is meaningful only for certain types, currently including
'hook', 'plist' and 'alist'. See the definition of the individual
types for a description of how to use ':options'.
You could use `choice', like this:
(defcustom foo 'cl-prin1
"..."
:type '(choice
(const cl-prin1)
(const prin1)
function)
:group 'convenience)
> > 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.
It's not the number of elements in the list that is the
limiting factor. It's apparently the size of the text
that is printed for a given backtrace line.
If you use larger list elements then you will see that
the list gets truncated.
(defun return-a-large-list ()
(let ((lst ()))
(dotimes (ii 5)
(push ctl-x-map lst))
lst))
Try to move over the list and you will see this error:
forward-sexp: Scan error: "Unbalanced parentheses", 36, 18171
Interestingly, this is also shown in *Messages*:
Entering debugger...
. ) . ) . ) . ) . ) . ) . ) . ) . ) . ) . ) . ) . ) . ) . ) . ) . ) . ) . )) . ) . ) . ) . ) . ) . ) . ) . ) . ) . ) . ) . ) . ) . ) . ) . ) . ) . ) . )) . ) . ) . ) . ) . ) . ) . ) . ) . ) . ) . ) . ) . ) . ) . ) . ) . ) . ) . )) . ) . ) . ) . ) . ) . ) . ) . ) . ) . ) . ) . ) . ) . ) . ) . ) . ) . ) . )) . ) . ) . ) . ) . ) . ) . ) . ) . ) . ) . ) . ) . ) . ) . ) . ) . ) . ) . )))
I have no idea why. Perhaps it is from vestigial debug messages?
> > 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?
> :)
It can be OK to change the default for a pretest only.
But in that case it should be made clear that that is
what's happening. Otherwise, people expect that the
pretest is showing what will be released, and that it
is therefore also a test of the change in default.
> We could turn it back for 26.1 still, I guess the
> maintainers should make this call.
Yes.
The biggest problem reported here is #3. I cannot move
over large Lisp sexps (e.g. lists) in the backtrace
entries and their parts, because they get truncated.
It would be good to be able to have pieces of a large
Lisp sexp elided, and to be able to toggle the elision
on/off.
^ permalink raw reply [flat|nested] 6+ messages in thread* bug#29077: 26.0; NEWS: "Values in call stack frames are now displayed using `cl-prin1'"
2017-10-31 16:41 ` Drew Adams
@ 2017-10-31 22:56 ` Noam Postavsky
2017-11-01 2:59 ` Drew Adams
0 siblings, 1 reply; 6+ messages in thread
From: Noam Postavsky @ 2017-10-31 22:56 UTC (permalink / raw)
To: Drew Adams; +Cc: 29077
Drew Adams <drew.adams@oracle.com> writes:
>> 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?
>
> Not really. Maybe there is no good solution. As (elisp) node
> `Variable Definitions' says about `:options':
>
> This is meaningful only for certain types, currently including
> 'hook', 'plist' and 'alist'. See the definition of the individual
> types for a description of how to use ':options'.
>
> You could use `choice', like this:
>
> (defcustom foo 'cl-prin1
> "..."
> :type '(choice
> (const cl-prin1)
> (const prin1)
> function)
Looks reasonable.
> :group 'convenience)
Did you mean to put this in? I don't see very many uses of :group
'convenience, and most are in defgroup forms.
> If you use larger list elements then you will see that
> the list gets truncated.
>
> (defun return-a-large-list ()
> (let ((lst ()))
> (dotimes (ii 5)
> (push ctl-x-map lst))
> lst))
Hmm, nope not seeing it. Do you get this from 'emacs -Q'? As far as I
can tell, there is nothing in cl-print.el that would perform truncation.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#29077: 26.0; NEWS: "Values in call stack frames are now displayed using `cl-prin1'"
2017-10-31 22:56 ` Noam Postavsky
@ 2017-11-01 2:59 ` Drew Adams
2017-11-01 13:23 ` Noam Postavsky
0 siblings, 1 reply; 6+ messages in thread
From: Drew Adams @ 2017-11-01 2:59 UTC (permalink / raw)
To: Noam Postavsky; +Cc: 29077
> > :group 'convenience)
>
> Did you mean to put this in? I don't see very many uses of :group
> 'convenience, and most are in defgroup forms.
No, not for this. I add a :group by habit. Emacs used to
complain if there isn't one. It was just a `foo' example.
> > If you use larger list elements then you will see that
> > the list gets truncated.
> >
> > (defun return-a-large-list ()
> > (let ((lst ()))
> > (dotimes (ii 5)
> > (push ctl-x-map lst))
> > lst))
>
> Hmm, nope not seeing it. Do you get this from 'emacs -Q'? As far as I
> can tell, there is nothing in cl-print.el that would perform truncation.
Damn! Such a waste of time. Sorry for the noise - it took
me a while to figure it out.
For some reason (I don't even recall) I had a copy of `cl-print.el'
that dated from 2017-09-10 in my load-path. That was being loaded.
Very sorry for the noise. Please close this bug.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-11-01 13:23 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-10-30 22:18 bug#29077: 26.0; NEWS: "Values in call stack frames are now displayed using `cl-prin1'" Drew Adams
2017-10-30 23:27 ` Noam Postavsky
2017-10-31 16:41 ` Drew Adams
2017-10-31 22:56 ` Noam Postavsky
2017-11-01 2:59 ` Drew Adams
2017-11-01 13:23 ` Noam Postavsky
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).