Dani Moncayo wrote: > Emacs uses M-p/M-n to browse the minibuffer history (and C-p/C-n to > move to the previous/next line in a multi-line buffer), whereas Bash > uses C-n/C-p for browsing the command history (and doesn't use M-p/M-n > for anything, AFAIK). > > It would be nice to remove this inconsistency (this is the obvious > part), and IMO TRT would be to make Bash behave like Emacs, that is: > 1. Use M-p/M-n to browse the command history (instead of the current C-p/C-n). > 2. Use C-p/C-n to move to the previous/next line, in the current > command being edited. > > WDYT?
This is completely putting the cart before the horse. And going down that road creates a circular line of reasoning which has no end to the loop cycle. Plus it is a radical change in fundamental behavior. Please don't. The entire reason that bash's readline emacs mode uses C-n and C-p is that those are the emacs keys for next-line and previous-line. If emacs were using M-p and M-n for previous and next then bash would have done so too. Bash didn't make this up. It is using the keys from emacs for emacs mode and those keys are C-n and C-p. Editing the history is just like editing a file. C-p takes you to the previous line. C-n takes you to the next line. Now enter emacs. I mean literally. (I have been using emacs for a very long time by the way. I am using it now.) Emacs has the feature including of being able to edit the minibuffer and also being able to run an inferior shell process in a buffer. Both are very similar cases and should be discussed together. In those buffers if you want to go to the previous line or the next line then what keys do you use? You use C-p and C-n to go to the previous line or the next line. But that is not editing the history. That is editing the buffer. There the previous and next lines are parts of the visible screen. It isn't a history of the screen. For using bash in an inferior shell if you want to recall shell history you can't use C-p and C-n because those are shadowed by the emacs layer of keybindings that move previous and next lines. Therefore M-p and M-n were the natural second choice to navigate by adding another mental layer of navigation. (Although emacs itself is keeping the input history.) Same thing for the minibuffer. So now people say, I am now used to using M-p and M-n in emacs to avoid the C-p/C-n. Let's set that up for bash. (Of course you can easily do this if you desire. Just do it. Several people suggested it.) Well, let's say for discussion that you get used to that setting. The entire argument so far is that people are "used to it". Now people become used to navigating the previous line with M-p and the next line with M-n in bash. Now they go to emacs. What do they do there? They find that in emacs M-p and M-n *do not navigate* the previous line and next line. They find that bash and emacs are once again inconsistent! In that future time let me file a bug with emacs asking for them to change their previous-line and next-line key bindings to be compatible with the new bash bindings of M-p and M-n for previous and next line. Why? Because they are "used to it". That request is just as valid as this request to do so with bash. So why not? Why wouldn't emacs change M-p and M-n to be previous line and next line? Let's say they do for continued discussion. Now in the future, future time where emacs has now adopted M-p and M-n for previous and next line. Now they need a way to escape the emacs layer again but with the new set of keys. In emacs I really don't want to need to use C-c as a prefix key for the minibuffer and the inferior shell buffer like in term mode. But let's say they do. Would there then be a request for bash to set up C-c M-n and C-c M-p for next and previous line? I think there would be and it would just be an endless cycle. As Chet said the mental model of what is happening at those two points of action in each program is different. Bob P.S. This is going to be a rant and run because I am offline for several days after this.
