1

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

andreas@my-computer:~/some/folder
$ #here

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

andreas@my-computer:~/some/folder
#here

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?

| improve this question | |
  • 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 '18 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". – Andreas Jansson Mar 16 '18 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 '18 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 '18 at 17:32
  • BTW, is C-a bound to comint-bol? – NickD Mar 16 '18 at 17:33
1

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

It was caused by ein:ipdb-buffer-initialize

| improve this answer | |
  • 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 '18 at 20:54

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.