7

I am having some trouble with helm, so I have set debug-on-error in an effort to locate the problem. Now whenever the problem occurs, the *Backtrace* buffer appears as expected, but I am still in one of helm's major modes and I am not able to navigate the backtrace buffer and debug normally.

The major mode is still using the minibuffer, and also seems to be "stealing" my key sequences and preventing me from debugging. When I exit the helm-mulit-occur in progress, the backtrace buffer is cleared and I cannot continue debugging.

Is there a way to "pause" a major mode while keeping the elisp debugger running so that I can debug as normal?

Improve this question
5
  • Which function is triggering the backtrace ? I used debug-on-entry on helm (debug-on-error would not get triggered as there were no errors) and am still able to debug.
    – Vamsi
    Commented Sep 29, 2014 at 17:51
  • @Vamsi: I am using helm-multi-occur and the specific error that is occurring some time after helm is successfully running is helm-interpret-value: Symbol must be a function or a variable.
    – nispio
    Commented Sep 29, 2014 at 18:05
  • In the keymap of this major mode, bind the key f5 to other-window. Then you should be able to switch away from it. Also, set enable-recursive-minibuffers to t.
    – Malabarba
    Commented Sep 29, 2014 at 20:13
  • @Malabarba: The command other-window does nothing in this mode, and the minibuffer seems to always have focus. C-h m is mapped to the command helm-help but manually running describe-mode tells me that I am in minibuffer-inactive-mode.
    – nispio
    Commented Sep 29, 2014 at 21:49
  • 1
    Looking at the backtrace, you should be able to tell which function is calling helm-interpret-value. Then you can Edebug it and find out what's happening.
    – Malabarba
    Commented Oct 2, 2014 at 16:08

3 Answers 3

Reset to default
3

The command helm-toggle-suspend-update is bound to C-! by default. It does not close helm, or end the recursive update, but it temporarily makes helm-mode much less "invasive." Suspending updates will keep helm from "stealing" all of your keyboard and mouse input, which can allow you to debug the helm process in another window.

Improve this answer
2

It isn't possible to "pause" a major mode, but as suggested in the comments to your questions it should be possible to move away from the buffer that triggered the error and to the backtrace buffer. If the mode of the buffer where the error occurred overrides the normal global bindings to move to another buffer then adding the key explicitly to its keymap might give you back the ability to select another buffer.

However it is also possible that the mode reads user input in a fancier way, making it impossible to move away. In the case of a completion buffer/mode like helm that could make sense.

However you might be able to simply quit helm and then go to *Backtrace*. The buffer won't be displayed in a window anymore, but it should still exist and contain the latest backtrace. You mention that the "backtrace buffer is cleared"; does the buffer simply disappears or is its content really cleared? In the latter case you might want to open an issue on the helm repository, as this could be considered a bug.

Improve this answer
7
  • While helm is still active, I have tried clicking in the backtrace buffer, rebinding key sequences, and calling M-x other-window directly, but none of these will allow me to take the focus away from the helm completion minibuffer. When the backtrace buffer first appears, it is the active window, but almost any keypress gets "stolen" by helm, and jumps me back into completion mode. When I exit helm with C-g the backtrace buffer is cleared, with no undo information.
    – nispio
    Commented Oct 2, 2014 at 14:27
  • 1
    Sounds like helm uses recursive editing (see (elisp)Recursive Editing. Makes sense for a package like helm but also means that quitting helm (by regularly invoking a command or aborting in your case) will return to the previous level, which causes to backtrace for the current level to be lost. So you were completely on the right track. Maybe helm already provides a solution to this, check its faq, otherwise open an issue. M-x fundamental-mode might also work, though it's also possible that this changes the mode in the wrong buffer.
    – tarsius
    Commented Oct 2, 2014 at 14:38
  • 1
    error parsing previous comment: unmatched parenthesis. ;-)
    – nispio
    Commented Oct 2, 2014 at 14:52
  • Don't really know what you mean by that.
    – tarsius
    Commented Oct 2, 2014 at 15:43
  • Please change the title. In most cases "debugging major modes" doesn't cause any problems; this issue is very specific to helm.
    – tarsius
    Commented Oct 2, 2014 at 15:44
0

Answering the question I came here for (the one in the title):

  • C-h C-d during a helm session
  • M-x helm-debug-open-last-log after a session

Which might help in your case as well, since part of the time logging makes it easier to find a problem than stepping through code.

You can find this information by pressing C-c ? during a helm session, or here.

Improve this answer

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.