Usually C-a moves point to just after the prompt:

$ #here

but occasionally something happens and C-a starts to the beginning of line:


I have no idea why this happens, and the only way I've been able to fix it is to restart Emacs. How can I revert C-a to the normal behavior of moving to the point after the prompt?

  • Check what function is bound to C-a both when it's working and when it isn't: you can do that with C-h c C-a RET. If they are different, that might provide a clue. Also, check that the mode is still shell-mode (e.g, with C-h v major-mode RET).
    – NickD
    Mar 16, 2018 at 16:30
  • thanks @Nick, they're no different. another side effect is that C-c C-c doesn't work on long-running processes inside the shell, it fails with "Text is read only". Mar 16, 2018 at 16:43
  • Maybe that's what you are doing: C-x C-q will toggle the read-only option on the buffer, so you may be pressing that inadvertently. The status line should tell you whether the buffer is read-only: if it is, try C-x C-q again to restore it to read-write But I can't reproduce the C-a behavior with just setting the buffer read-only.
    – NickD
    Mar 16, 2018 at 17:28
  • Have you tried M-x shell-mode RET when it's in the funky state? Maybe that will restore the proper C-a behavior.
    – NickD
    Mar 16, 2018 at 17:32
  • BTW, is C-a bound to comint-bol?
    – NickD
    Mar 16, 2018 at 17:33

1 Answer 1


Fixed by invoking (setq comint-use-prompt-regexp nil).

It was caused by ein:ipdb-buffer-initialize

  • 1
    That variable already defaults to nil, so please expand your answer to include some explanation of why it was set otherwise in the first place.
    – Stefan
    Nov 8, 2018 at 20:54

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.