> I said in an earlier message that the two programs use different mental > models. Here's what I meant.
Currently they are different, indeed, but I think it would be perfectly possible, and desirable, to remove that inconsistency. > 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. This is the current situation, but I don't think it is consistent. The fact that readline is one-dimensional as you say should not be an impediment for adopting the Emacs model in bash: Just use M-p/M-n to move across commands. If currently the commands in Bash can't have multiple lines of text, then C-p and C-n would have no use. But if in the future, readline is improved and gets support for multiline commands, the C-p/C-n would be really useful. > 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. Again: Bash could use the same set of key bindings as Emacs does. I was proposing to remove the inconsistency upstream, because so far, I think it is perfectly possible. >> 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 thought that compatibility with GNU Emacs was important too. Perhaps the proposed (Emacs-compatible) behavior could be made optional? > 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/ -- Dani Moncayo
