unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: npostavs@users.sourceforge.net
To: Stefan Monnier <monnier@IRO.UMontreal.CA>
Cc: lekktu@gmail.com, johnw@gnu.org, 6991@debbugs.gnu.org, larsi@gnus.org
Subject: bug#6991: Please keep bytecode out of *Backtrace* buffers
Date: Mon, 26 Jun 2017 08:50:47 -0400	[thread overview]
Message-ID: <87h8z2oqu0.fsf@users.sourceforge.net> (raw)
In-Reply-To: <jwvpodr9znt.fsf-monnier+emacs@gnu.org> (Stefan Monnier's message of "Mon, 26 Jun 2017 00:02:17 -0400")

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> It does replace the functionality of debugger-make-xrefs.  But
>> `ert--make-xrefs-region' is still using `debugger-make-xrefs', and I
>> don't quite see how to remove that usage.
>
> I see.  Maybe we should move it to ert.el, then?

Sure.

>>>> +          (print-escape-newlines t)
>>>> +          (print-level 8)
>>>> +          (print-length 50))
>>> 
>>> Why let-bind print-* here rather than inside debugger-insert-backtrace?
>
>> I thought moving those inside might needlessly make the function less
>> flexible, though nobody is currently making use of the flexibility so
>> maybe it's not worth it...
>
> Hmm... I can agree with it for level and length, but I think that the
> escape-newline behavior is indispensable.

Okay, that makes sense.

>>>> +      (when (eq (car args) 'exit)
>>>> +        (setf (cl-getf (nth 3 (car frames)) :debug-on-exit) nil))
>>> 
>>> This looks like code which was moved from elsewhere, yet I can't find
>>> this elsewhere in your patch(es).  What am I missing?
>
>> backtrace--print-frame I guess?  I haven't changed the printing for
>> `backtrace', perhaps I should...
>
> Hmm... I don't see anything that corresponds to this setf in
> backtrace--print-frame.  What do the above 2 lines do, and where is the
> corresponding code in the current debug.el?  Or is that a new feature in
> your code?  (if so, where is it documented in the commit message?)

Ah, sorry, my memory of the old code got a little fuzzy, it doesn't
correspond to backtrace--print-frame (that function only contains the
code which reads the :debug-on-exit flag).  It's actually replacing the
code removed in this hunk:

@@ -301,10 +319,7 @@ (defun debugger-setup-buffer (args)
        (setq pos (point))
        (setq debugger-value (nth 1 args))
        (prin1 debugger-value (current-buffer))
-       (insert ?\n)
-       (delete-char 1)
-       (insert ? )
-       (beginning-of-line))
+       (insert ?\n))
       ;; Watchpoint triggered.
       ((and `watchpoint (let `(,symbol ,newval . ,details) (cdr args)))
        (insert

So it's another instance of operating on the backtrace frame object
directly, instead of manipulating the text after printing (i.e.,
unsetting the :debug-on-exit flag instead of erasing its representation
"*" in the buffer).

Also, as I'm looking at this, I wonder if I should replace the (prin1
debugger-value ...) calls with (funcall debugger-print-function ...)
too.  Hmm, and I probably shouldn't have moved those print-*
let-bindings at all because they could be relevant to the code printing
"frame 0".





  reply	other threads:[~2017-06-26 12:50 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-07  1:35 bug#6991: Please keep bytecode out of *Backtrace* buffers jidanni
2012-02-22  1:02 ` Glenn Morris
2012-02-22 16:43   ` Drew Adams
2012-02-22 17:01     ` Juanma Barranquero
2012-07-02 17:40       ` Drew Adams
2012-07-02 18:38         ` Stefan Monnier
2012-07-02 19:06           ` Drew Adams
2013-01-24 22:43             ` Drew Adams
     [not found]             ` <<FEE817DF5DCC41CD9156B414FF2088D1@us.oracle.com>
2013-08-07 22:25               ` Drew Adams
2016-02-26  6:41           ` Lars Ingebrigtsen
2016-02-26 14:11             ` Drew Adams
2016-02-27  0:52               ` John Wiegley
2016-02-27  1:49                 ` Drew Adams
2016-11-19  1:55                   ` npostavs
2016-11-19  2:37                     ` Drew Adams
2016-11-19  7:41                     ` Eli Zaretskii
2016-11-19 14:39                       ` npostavs
2016-11-19 15:07                         ` Eli Zaretskii
2016-11-19 15:20                           ` npostavs
2016-11-19 18:34                             ` Eli Zaretskii
2016-11-19 22:33                               ` npostavs
2016-11-20 15:46                                 ` Eli Zaretskii
2016-11-22 18:07                                   ` Noam Postavsky
2016-11-22 18:52                                     ` Eli Zaretskii
2016-11-22 21:07                                       ` Noam Postavsky
2016-11-23 16:05                                         ` Eli Zaretskii
2016-11-26 17:18                                           ` npostavs
2016-11-26 18:54                                             ` Stefan Monnier
2017-02-12  2:26                                               ` npostavs
2017-05-28 14:58                                                 ` npostavs
2017-06-24 22:27                                                   ` npostavs
2017-06-25 19:11                                                     ` Stefan Monnier
2017-06-26  3:34                                                       ` npostavs
2017-06-26  4:02                                                         ` Stefan Monnier
2017-06-26 12:50                                                           ` npostavs [this message]
2017-06-26 14:54                                                             ` Stefan Monnier
2017-06-27  3:56                                                               ` npostavs
2017-06-27 16:18                                                                 ` Stefan Monnier
2017-06-29 23:52                                                                   ` npostavs
2016-11-26 23:45                                             ` Richard Stallman
2016-11-27  0:33                                               ` Noam Postavsky
2016-11-27  3:34                                                 ` Clément Pit--Claudel
2016-11-27  3:36                                                 ` Eli Zaretskii
2016-11-27 14:10                                                   ` Noam Postavsky
2016-11-27 23:21                                                 ` Richard Stallman
2016-11-19 17:08                       ` Richard Stallman
2016-02-27  4:13                 ` Lars Ingebrigtsen
2017-09-11 10:57 ` bug#6991: Rocky Bernstein
2017-09-11 14:28   ` bug#6991: Eli Zaretskii
2017-09-13  1:13     ` bug#6991: Rocky Bernstein

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87h8z2oqu0.fsf@users.sourceforge.net \
    --to=npostavs@users.sourceforge.net \
    --cc=6991@debbugs.gnu.org \
    --cc=johnw@gnu.org \
    --cc=larsi@gnus.org \
    --cc=lekktu@gmail.com \
    --cc=monnier@IRO.UMontreal.CA \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).