3

when I enable debug on error it works perfectly the first time.

when I go and fix my error and rerun my function debug on error no longer triggers for new errors.

Is there a way to enable it so future debugs work as well instead of me having to quit and reload emacs to reset the functionality ?

This is an example of what i get, but only ever once.

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  file-name-directory(nil)
  (message "dc-compose-root %s" (file-name-directory buffer-file-name))
  dc-compose-root()
  (format "dc-compose-exits%s%s" (dc-compose-root) dc-docker-compose-file)
  (file-exists-p (format "dc-compose-exits%s%s" (dc-compose-root) dc-docker-compose-file))
  dc-compose-exists()
  (if (dc-compose-exists) t (error "Missing docker-compose.yml in project root aborting current command %s" (dc-compose-root)))
  dc-compose-exists-check()
  dc-docker-compose-process(#("[C-t] show common commands, [?] describe events, [C-h i] show manualps" 1 4 (face magit-popup-key) 29 30 (face magit-popup-key) 50 55 (face magit-popup-key)))
  dc-docker-compose-ps(#("[C-t] show common commands, [?] describe events, [C-h i] show manual" 1 4 (face magit-popup-key) 29 30 (face magit-popup-key) 50 55 (face magit-popup-key)))
  funcall-interactively(dc-docker-compose-ps #("[C-t] show common commands, [?] describe events, [C-h i] show manual" 1 4 (face magit-popup-key) 29 30 (face magit-popup-key) 50 55 (face magit-popup-key)))
  call-interactively(dc-docker-compose-ps)
  magit-invoke-popup-action(112)
  funcall-interactively(magit-invoke-popup-action 112)
  call-interactively(magit-invoke-popup-action nil nil)
  command-execute(magit-invoke-popup-action)
Improve this question
6
  • 1
    Provide more info. Show some code - what you tried. debug-on-error does not raise an error in some contexts where doing so would be problematic (but I doubt that is the problem you are encountering).
    – Drew
    Commented Oct 10, 2017 at 14:18
  • its not an issue with code, i have put the output i see what does not happen is that view only ever happens once. so when i edit my code and make a mistake i get an error in the messages buffer but the traceback does not trigger again.
    – Oly
    Commented Oct 10, 2017 at 14:27
  • 6
    Perhaps you didn't exit the debugger session? See (emacs) Recursive Edit
    – npostavs
    Commented Oct 10, 2017 at 15:16
  • Your quite right, I did not know that was a thing and the backtrace buffer does not have shortcut help from what i can see. basically CTRL-] quits the traceback and means future errors are caught. If you want to add as an answer i will accept :)
    – Oly
    Commented Oct 10, 2017 at 15:32
  • 3
    Use C-h m' in any buffer to know about its mode. If you do that in buffer *Backtrace*` you will see that you can hit q to quit, etc.
    – Drew
    Commented Oct 10, 2017 at 17:55

1 Answer 1

Reset to default
0

Basically, getting the *Backtrace* buffer inhibits further triggering. Then, some ways of switching off of the buffer will uninhibit it while others don't. Leaving it inhibited may actually be useful for some usecases, confusing nonetheless. Re-enabling toggle-debug-on-error won't do anything in this case.

Here are the ways to exit the buffer that would uninhibit triggering:

  • Pressing q while inside *Backtrace* buffer
  • Killing the buffer

And these would leave it inhibited, leading to the problem described:

  • Closing the "window" with Ctrl+x 0
  • Simply switching off to another buffer with Ctrl+x b

To uninhibit the functional in these cases just perform anything enlisted in the "uninhibiting" list.

It is interesting to note that even though pressing q looks as if it just switches to another buffer (it does not kill *Backtrace*), it has the necessary side effect of uninhibiting triggering.

Improve this answer
1
  • 2
    It's not about "inhibiting" vs "not inhibiting" other backtraces. The backtrace buffer is a part of an active debugging session (of which you can only have one). Until you quit the debugger other backtraces will indeed be inhibited, but moreover you can also interact with the debugger!. You can step through code, evaluate code in the context of different frames, etc, etc. Start reading at C-h i g (elisp)Debugger to understand what you can do.
    – phils
    Commented Oct 26, 2023 at 21:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.