Emacs does generally use C-p
and C-n
for moving the cursor up and down, <up>
and <down>
are usually bound to the same command. That's why you get the unfamiliar behaviour of the arrow keys not cycling the history. As a compromise M-p
and M-n
are bound in these contexts to history cycling commands. The only exception I'm aware of would be term-mode
which captures nearly all of your input and passes it on to the application.
You can of course adjust the respective keymaps to get the familiar behaviour back, but be warned that this will prevent you from moving the cursor elsewhere with the keyboard (the mouse can still be used to position it anywhere though). The general approach to this is finding out what commands are bound to the respective keys (F1 k <key sequence>
) and what keymap they belong to (Emacs 25 provides this in the output of F1 k
, but as I'm not using that, I jump to the sources with the link present in the F1 k
output and search these). Doing so reveals that the commands are previous-line
/next-line
and comint-previous-input
/comint-next-input
, the latter two being bound in comint-mode-map
. Therefore, the following suffices:
(eval-after-load 'comint
'(progn
(define-key comint-mode-map (kbd "<up>") 'comint-previous-input)
(define-key comint-mode-map (kbd "C-p") 'comint-previous-input)
(define-key comint-mode-map (kbd "<down>") 'comint-next-input)
(define-key comint-mode-map (kbd "C-n") 'comint-previous-input)))
M-p
andM-n
work?<up>
and<down>
to do the same things asM-p
andM-n
. Preventing the cursor to move away from the prompt is going to be tricky or impossible considering there's the usecase of selecting something outside it which needs to move point as it makes up the region. Would you still like me to turn the solution to this into an answer?