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

[Drew Adams]

> >  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.