bug-bash
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]