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, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
