unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
* Entering backtrace buffer if displayed information is huge
@ 2019-10-07 14:29 Wolfgang Pausch
  2019-10-08 12:13 ` Robert Pluim
  2019-10-08 17:55 ` Stefan Monnier
  0 siblings, 2 replies; 5+ messages in thread
From: Wolfgang Pausch @ 2019-10-07 14:29 UTC (permalink / raw)
  To: help-gnu-emacs

Hello,

I'm implementing some lisp code based on js2-mode.  The nodes of the 
abstract syntax tree of that mode frequently need to be passed between 
defuns.

My problem is that the Backtrace buffer tries to display the huge 
contents of that nodes, and this makes entering the Backtrace buffer 
extremely slow, and sometimes impossible at all.

(and once opened, each editor move within the Backtrace buffer can cause 
emacs to freeze for an additional time)

What's a senseful way to debug in such situations?  Basically, if the 
contents of the variables passed to a defun are too huge to be displayed 
in a efficient manner, at least the names of the functions being called 
would be a help while debugging --- is it somehow possible to restrict 
opening a Backtrace buffer to such more basic information?

Currently, I have the situation that debugging trivial programming 
problems costs way too much time...

Thanks for all hints,

Wolfgang



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Entering backtrace buffer if displayed information is huge
  2019-10-07 14:29 Entering backtrace buffer if displayed information is huge Wolfgang Pausch
@ 2019-10-08 12:13 ` Robert Pluim
  2019-10-08 12:25   ` Wolfgang Pausch
  2019-10-08 17:55 ` Stefan Monnier
  1 sibling, 1 reply; 5+ messages in thread
From: Robert Pluim @ 2019-10-08 12:13 UTC (permalink / raw)
  To: Wolfgang Pausch; +Cc: help-gnu-emacs

>>>>> On Mon, 7 Oct 2019 17:29:54 +0300, Wolfgang Pausch <wolfgang.pausch@iteg.at> said:

    Wolfgang> Hello,
    Wolfgang> I'm implementing some lisp code based on js2-mode.  The nodes of the
    Wolfgang> abstract syntax tree of that mode frequently need to be passed between 
    Wolfgang> defuns.

    Wolfgang> My problem is that the Backtrace buffer tries to display the huge
    Wolfgang> contents of that nodes, and this makes entering the Backtrace buffer 
    Wolfgang> extremely slow, and sometimes impossible at all.

    Wolfgang> (and once opened, each editor move within the Backtrace buffer can
    Wolfgang> cause emacs to freeze for an additional time)

    Wolfgang> What's a senseful way to debug in such situations?  Basically, if the
    Wolfgang> contents of the variables passed to a defun are too huge to be
    Wolfgang> displayed in a efficient manner, at least the names of the functions
    Wolfgang> being called would be a help while debugging --- is it somehow
    Wolfgang> possible to restrict opening a Backtrace buffer to such more basic
    Wolfgang> information?

    Wolfgang> Currently, I have the situation that debugging trivial programming
    Wolfgang> problems costs way too much time...

    Wolfgang> Thanks for all hints,

Does setting 'print-length' to something sensible help?

Robert



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Entering backtrace buffer if displayed information is huge
  2019-10-08 12:13 ` Robert Pluim
@ 2019-10-08 12:25   ` Wolfgang Pausch
  2019-10-08 12:52     ` Michael Heerdegen
  0 siblings, 1 reply; 5+ messages in thread
From: Wolfgang Pausch @ 2019-10-08 12:25 UTC (permalink / raw)
  To: help-gnu-emacs

> Does setting 'print-length' to something sensible help?

Current situation: print-length is set to nil, and as far as I see not 
customizable; documentation redirects me to eval-expression-print-length.

eval-expression-print-length has the value 12.

Is this "something sensible", or do you mean I should try to set a value 
of print-length directly beside the fact that it's not marked as 
customizable?

Wolfgang



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Entering backtrace buffer if displayed information is huge
  2019-10-08 12:25   ` Wolfgang Pausch
@ 2019-10-08 12:52     ` Michael Heerdegen
  0 siblings, 0 replies; 5+ messages in thread
From: Michael Heerdegen @ 2019-10-08 12:52 UTC (permalink / raw)
  To: Wolfgang Pausch; +Cc: help-gnu-emacs

Wolfgang Pausch <wolfgang.pausch@iteg.at> writes:

> Is this "something sensible", or do you mean I should try to set a
> value of print-length directly beside the fact that it's not marked as
> customizable?

Just play around with it, you can use a different Emacs session for
testing - you can later advice the debugger to use a binding that works
well for you.  Should be harmless anyway.

Just do M-: (setq print-length 20) RET or so and see if it helps.
Likewise with print-level (if your backtrace included lots of deeply
nested objects, that might be more effective).

Michael.



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Entering backtrace buffer if displayed information is huge
  2019-10-07 14:29 Entering backtrace buffer if displayed information is huge Wolfgang Pausch
  2019-10-08 12:13 ` Robert Pluim
@ 2019-10-08 17:55 ` Stefan Monnier
  1 sibling, 0 replies; 5+ messages in thread
From: Stefan Monnier @ 2019-10-08 17:55 UTC (permalink / raw)
  To: help-gnu-emacs

> My problem is that the Backtrace buffer tries to display the huge contents
> of that nodes, and this makes entering the Backtrace buffer extremely slow,
> and sometimes impossible at all.

Supposedly, this should be fixed in the `master` branch of Emacs (to
become 27.1).


        Stefan




^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2019-10-08 17:55 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-10-07 14:29 Entering backtrace buffer if displayed information is huge Wolfgang Pausch
2019-10-08 12:13 ` Robert Pluim
2019-10-08 12:25   ` Wolfgang Pausch
2019-10-08 12:52     ` Michael Heerdegen
2019-10-08 17:55 ` Stefan Monnier

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