Re: Browsing the history of commands. Inconsistency between Bash and Emacs
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. I disagree with the above, obviously. See below. 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. Then, that model used in bash is precisely what I think should be changed (generalized), to match the emacs one: Emacs' minibuffer distinguishes between (a) different lines within the current command and (b) different commands. And that distinction is good, because it allows for a richer user interface: you can, on one hand, move across different commands (with M-p/M-n), and OTOH, move across different lines in the current selected command (with C-p/C-n). It is simply a richer (better) model, IMHO. 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. I definitely think they are different scenarios. But see below. 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. Of course: you are in a buffer in Emacs, and the standard commands to move across lines within a buffer are those (C-p/C-n). But that is not editing the history. That is editing the buffer. Indeed. 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. That is another example of the inconsistency I'd like to remove: In Emacs, the standard commands for moving across histories (commands, files, buffers, bookmarks, etc) are M-p and M-n. And for that reason, you have to use those keys for browsing the command history of the inferior shell (and C-p/C-n are, as always, employed for moving across lines in the current buffer). 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.) Yes, I can do it in my .bashrc, but the point is to remove this inconsistency upstream. 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. No. See above. The entire argument is that Emacs uses a more general and richer model, and it would be nice if Bash could adopt that same model. 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! Not at all. They find that in Emacs, M-p and M-n, as always, are for navigating across consecutive entries (whether multiline or single-line) in every history of elements (including commands). And that would be perfectly consistent with Bash (if it used M-p/M-n for the same purpose, instead of C-p/C-n). 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. Not at all. See above. Againg: Emacs would not have to change anything to be consistent with Bash: * M-p/M-n for browsing the history. * C-p/C-n for moving across lines within a single entry/buffer. I think/hope that my point is clear enough already. -- Dani Moncayo
Browsing the history of commands. Inconsistency between Bash and Emacs
Hello, Bash developers, (I know little about Bash, so I apologize beforehand if I say something inaccurate or nonsensical) Bug #16740 was filed today against the Emacs package, asking to remove an inconsistency between the keys employed by Emacs and Bash to browse the history of commands. See: http://lists.gnu.org/archive/html/bug-gnu-emacs/2014-02/msg01082.html 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? -- Dani Moncayo
Re: Browsing the history of commands. Inconsistency between Bash and Emacs
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.
Re: Browsing the history of commands. Inconsistency between Bash and Emacs
On 2/13/14, 9:40 AM, Dani Moncayo wrote: Hello, Bash developers, (I know little about Bash, so I apologize beforehand if I say something inaccurate or nonsensical) Bug #16740 was filed today against the Emacs package, asking to remove an inconsistency between the keys employed by Emacs and Bash to browse the history of commands. See: http://lists.gnu.org/archive/html/bug-gnu-emacs/2014-02/msg01082.html 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). I said in an earlier message that the two programs use different mental models. Here's what I meant. Readline is one-dimensional: everything it deals with is a line. Emacs is two-dimensional: there is a (logical) array of lines presented a screenful at a time. Emacs uses C-p and C-n to move between lines; even when in a shell minibuffer, C-p and C-n can be used to move around previous command output. Since readline is one-dimensional, the way you add a second dimension is through the history. It doesn't, and can't, know anything about the rest of the screen's contents. It's only concerned with the current line. Readline uses C-p and C-n to move up and down through its units of lines: the history. This is consistent. Emacs needed a different set of key bindings to move through the history, and it chose M-p and M-n. Users who want that kind of consistency can easily bind M-p and M-n to previous-history and next-history, respectively. 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. No. The use of C-p and C-n for this is pervasive and long-lived. There is no reason to break 25 years of backwards compatibility and compatibility with other shells to make this change. I'm not opposed to looking at a readline command to move through physical lines of a line containing embedded newlines (rare) or a line exceeding the screen width that ends up getting wrapped (common), as long as such a command can be specified and implemented. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
