I have a function bound to Ctrl-b, this runs a command immediately, however after some time running emacs, pressing this binding shows text C-b in the message bar, prompting for other keys to be pressed.

If I press Enter, it runs the command, otherwise it keeps accepting key and mouse input.

C-h k still shows up this key binding as being associated with the function I expect it to run.

How to troubleshoot emacs expecting further input for a key binding?

Edit: the command (which I wasn't sure if it was important) is to build.

(defun generic-build ()
    ((string= major-mode "c-mode")
      (call-interactively 'cmake-ide-compile))
    ((string= major-mode "c++-mode")
      (call-interactively 'cmake-ide-compile))

(global-set-key (kbd "C-b") 'generic-build)
(eval-after-load "evil-maps"
  (define-key evil-motion-state-map "\C-b" nil))

Update 1:

This happens if I try to exit too, Pressing Ctrk-b, Ctrl-h shows this message.

This would have to be related to my configuration, the issue just never came up until recently.

Type SPC or ‘y’ to save the current buffer;
DEL or ‘n’ to skip the current buffer;
RET or ‘q’ to give up on the save (skip all remaining buffers);
C-g to quit (cancel the whole command);
! to save all remaining buffers;
C-r to view this buffer;
d to view changes in this buffer;
or . (period) to save the current buffer and exit.

I'm using:

(setq use-dialog-box nil)

Which has been working up until now.

Using emacs -Q, then setting (setq use-dialog-box nil) still prompts for file save.

Update 2:

Found the root cause, posting in answer since its confusing to include here.

  • If it had been converted to a prefix binding then you could type C-b C-h to see which bindings were using that prefix; however that does not match your description. Please update the question with details of the specific function in question. My best guess is that this is actually expected behaviour. – phils Mar 13 '18 at 11:18
  • It's a function I wrote, it simply triggers a build. It doesnt do anything interactive. The reason this is not expected behavior is it does not do this when I first open emacs. after 10min use+ ... it starts to do it (not scientific I know, I'm just not sure what triggers it). – ideasman42 Mar 13 '18 at 13:41
  • Do you see the same problem when you start Emacs with emacs -Q (no init file), and then define your command and bind it to the key? If not, bisect your init file to find the culprit. – Drew Mar 13 '18 at 16:38
  • 1
    As phils wrote, either C-b C-h or C-b ? will tell you what bindings are available. Some of those bindings must have overwritten your original one. – wvxvw Mar 13 '18 at 19:07
  • Show us the function. – phils Mar 13 '18 at 19:49

Glad to know you resolved the problem. Since your question is about troubleshooting keybindings I'd like to chip in with my key troubleshooting process.

Try using C-h b when you can't properly query C-h k for the command bound to a key.
The C-h b (M-x describe-bindings) command describes all active key bindings for the buffer.

It's easy to scan this table for any clashes with an existing prefix command. A clash of this type could explain why your key was waiting for more key stroke input.

When a problem happens only after I've been interacting with Emacs for some time this is often because I indirectly loaded features when searching for their documentation with C-h f and C-h v.

In this case comparing the output of C-h m could help find problems introduced when a new mode is loaded, maybe unexpectedly or inadvertently.


This problem is messages are being suppressed by this advice-function.

somehow it's not limited to ispell-init-process:

(defun message-off-advice (oldfun &rest args)
  "Quiet down messages in adviced OLDFUN."
  (let ((message-off (make-symbol "message-off")))
      (advice-add #'message :around #'ignore (list 'name message-off))
      (apply oldfun args))
      (advice-remove #'message message-off))))

(advice-add #'ispell-init-process :around #'message-off-advice)

See answer: https://emacs.stackexchange.com/a/36626/2418

  • "somehow it's not limited to ispell-init-process" - yes, it completely disables message when ispell-init-process is called until that call ends. That includes asynchronous calls, since I see that ispell-init-process uses accept-process-output. – npostavs Apr 13 '18 at 11:26

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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