* 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
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.