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?

  • 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 Sep 29 '14 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 Sep 29 '14 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 Sep 29 '14 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 Sep 29 '14 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 Oct 2 '14 at 16:08

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.


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.

  • 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 Oct 2 '14 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 Oct 2 '14 at 14:38
  • 1
    error parsing previous comment: unmatched parenthesis. ;-) – nispio Oct 2 '14 at 14:52
  • Don't really know what you mean by that. – tarsius Oct 2 '14 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 Oct 2 '14 at 15:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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