[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Browsing the history of commands. Inconsistency between Bash and Ema
From: |
Dani Moncayo |
Subject: |
Re: Browsing the history of commands. Inconsistency between Bash and Emacs |
Date: |
Fri, 14 Feb 2014 14:24:57 +0100 |
> 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 chet@case.edu http://cnswww.cns.cwru.edu/~chet/
--
Dani Moncayo