From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#29077: 26.0; NEWS: "Values in call stack frames are now displayed using `cl-prin1'" Date: Tue, 31 Oct 2017 09:41:04 -0700 (PDT) Message-ID: <4e5dca46-09f8-4fbd-8a4c-054ee6eacd5d@default> References: <87h8ugb4i6.fsf@users.sourceforge.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1509468143 10980 195.159.176.226 (31 Oct 2017 16:42:23 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 31 Oct 2017 16:42:23 +0000 (UTC) Cc: 29077@debbugs.gnu.org To: Noam Postavsky Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Oct 31 17:42:15 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e9ZcC-0001YC-6c for geb-bug-gnu-emacs@m.gmane.org; Tue, 31 Oct 2017 17:42:12 +0100 Original-Received: from localhost ([::1]:46569 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e9ZcH-0007nn-Rf for geb-bug-gnu-emacs@m.gmane.org; Tue, 31 Oct 2017 12:42:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33292) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e9Zc9-0007nW-44 for bug-gnu-emacs@gnu.org; Tue, 31 Oct 2017 12:42:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e9Zc3-0002eE-6Y for bug-gnu-emacs@gnu.org; Tue, 31 Oct 2017 12:42:09 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:35759) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1e9Zc3-0002e2-1N for bug-gnu-emacs@gnu.org; Tue, 31 Oct 2017 12:42:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1e9Zc1-0006un-Ou for bug-gnu-emacs@gnu.org; Tue, 31 Oct 2017 12:42:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 31 Oct 2017 16:42:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 29077 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 29077-submit@debbugs.gnu.org id=B29077.150946807626511 (code B ref 29077); Tue, 31 Oct 2017 16:42:01 +0000 Original-Received: (at 29077) by debbugs.gnu.org; 31 Oct 2017 16:41:16 +0000 Original-Received: from localhost ([127.0.0.1]:44440 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e9ZbI-0006tX-7z for submit@debbugs.gnu.org; Tue, 31 Oct 2017 12:41:16 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:44523) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e9ZbF-0006tH-FT for 29077@debbugs.gnu.org; Tue, 31 Oct 2017 12:41:14 -0400 Original-Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v9VGf6Zx028997 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 31 Oct 2017 16:41:07 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v9VGf62P012764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 31 Oct 2017 16:41:06 GMT Original-Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v9VGf5Mh027576; Tue, 31 Oct 2017 16:41:05 GMT In-Reply-To: <87h8ugb4i6.fsf@users.sourceforge.net> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4600.0 (x86)] X-Source-IP: userv0022.oracle.com [156.151.31.74] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:139271 Archived-At: > > 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. >=20 > 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'). >=20 > 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*,=20 > > being able to move over full Lisp objects such as lists. > > > > I don't see this problem in previous Emacs releases. >=20 > 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. >=20 > 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=20 > 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.