bug#16740: 24.2; Please allow C-p and C-n in minibuffer

bug#16740: 24.2; Please allow C-p and C-n in minibuffer

[Ed Avis]

This bug report will be sent to the Bug-GNU-Emacs mailing list
and the GNU bug tracker at debbugs.gnu.org.  Please check that
the From: line contains a valid email address.  After a delay of up
to one day, you should receive an acknowledgement at that address.

Please write in English if possible, as the Emacs maintainers
usually do not have translators for other languages.

Please describe exactly what actions triggered the bug, and
the precise symptoms of the bug.  If you can, give a recipe
starting from `emacs -Q':

Do C-x C-f f o o RET.  This opens a file called foo.
Now C-x k, to close that buffer.
Now we attempt to open the file again: C-x C-f C-p.
That doesn't work; C-p was intended to get the previous filename
but gives 'beginning of buffer'.  You need to type M-p instead.

However, in GNU bash, the situation is reversed.  To get the previous
command line you have to hit C-p, and M-p just enters a control
sequence.  So there is a user interface inconsistency between
bash and Emacs.

I think the best way to resolve it is to make C-p and C-n work in
the Emacs minibuffer to get the previous and next lines from the
history, just as M-p and M-n do.  Since the minibuffer is almost
always a single line of text, the bindings to previous-line and
next-line aren't helpful in the minibuffer.

If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
For information about debugging Emacs, please read the file
/usr/share/emacs/24.2/etc/DEBUG.


In GNU Emacs 24.2.1 (x86_64-redhat-linux-gnu, GTK+ Version 3.6.4)
 of 2013-07-14 on buildvm-05.phx2.fedoraproject.org
Configured using:
 `configure '--build=x86_64-redhat-linux-gnu'
 '--host=x86_64-redhat-linux-gnu' '--program-prefix='
 '--disable-dependency-tracking' '--prefix=/usr' '--exec-prefix=/usr'
 '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc'
 '--datadir=/usr/share' '--includedir=/usr/include'
 '--libdir=/usr/lib64' '--libexecdir=/usr/libexec'
 '--localstatedir=/var' '--sharedstatedir=/var/lib'
 '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-dbus'
 '--with-gif' '--with-jpeg' '--with-png' '--with-rsvg' '--with-tiff'
 '--with-xft' '--with-xpm' '--with-x-toolkit=gtk3' '--with-gpm=no'
 '--with-wide-int' 'build_alias=x86_64-redhat-linux-gnu'
 'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS=-DMAIL_USE_LOCKF -O2 -g
 -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
 --param=ssp-buffer-size=4 -m64 -mtune=generic' 'LDFLAGS=-Wl,-z,relro ''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: C
  value of $LC_CTYPE: en_GB.UTF-8
  value of $LC_MESSAGES: en_GB.UTF-8
  value of $LC_MONETARY: en_GB.UTF-8
  value of $LC_NUMERIC: en_GB.UTF-8
  value of $LC_TIME: en_GB.UTF-8
  value of $LANG: en_GB.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Perl

Minor modes in effect:
  diff-auto-refine-mode: t
  shell-dirtrack-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
SPC t h e SPC q u e u e . C-c C-c C-x b W a c TAB C-g
C-x o DEL C-d RET C-x C-f l i b / W a c TAB T TAB RET
C-s s a m e _ C-a C-s w a r n _ s a m e _ C-s C-s C-s
C-s C-s C-r C-r C-r C-a C-x 1 C-f C-f C-f C-f C-f C-f
C-f C-s C-w C-w C-w C-s C-s C-s C-a C-r $ f i l l C-r
C-r C-r C-r C-r C-r C-s C-s C-s C-a C-p C-p C-p C-p
C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p
C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p
C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p
C-p C-p C-p RET RET C-p TAB @ SPC DEL DEL # SPC N B
SPC DEL DEL DEL W e SPC u s e d SPC t o SPC m a k e
SPC s u r e SPC t h a t SPC w a r n _ s a m _ e d a
DEL DEL DEL DEL e _ d a y s SPC w a s SPC a t SPC l
e a s t SPC f i l l + 1 . SPC SPC S o SPC i f SPC a
SPC s e r i e s SPC i s RET TAB # SPC r e a l l y SPC
f i l l e d SPC C-x k RET y e s RET C-x b RET q C-x
C-f C-p C-x C-f ESC p RET ESC x r e p o r t SPC e m
SPC b SPC RET

Recent messages:
Press C-c C-c when you are done editing.
Enter a change comment.  Type C-c C-c when done
Mark saved where search started
Mark set [2 times]
Saving file /home/eda/svn_working/repos/scripts/send_deferred_emails...
Wrote /home/eda/svn_working/repos/scripts/send_deferred_emails
Checking in /home/eda/svn_working/repos/scripts/send_deferred_emails...done
Quit
Mark saved where search started [4 times]
line-move-visual: Beginning of buffer
Quit

Load-path shadows:

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________

bug#16740: 24.2; Please allow C-p and C-n in minibuffer

[Andreas Schwab]

Ed Avis <eda@waniasset.com> writes:

> I think the best way to resolve it is to make C-p and C-n work in
> the Emacs minibuffer to get the previous and next lines from the
> history, just as M-p and M-n do.  Since the minibuffer is almost
> always a single line of text, the bindings to previous-line and
> next-line aren't helpful in the minibuffer.

IMHO it should be rather the other way round, and bash/readline should
be changed.  When editing a multiline minibuffer then C-n/C-p should
just navigate within it.  In readline there doesn't seem to be a way to
go to the previous line of a multiline buffer except by horizonal
movement over the newline, which is annoying.

Note that in Emacs the cursor keys already work like M-n/M-p.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

bug#16740: 24.2; Please allow C-p and C-n in minibuffer

[Dani Moncayo]

> Do C-x C-f f o o RET.  This opens a file called foo.
> Now C-x k, to close that buffer.
> Now we attempt to open the file again: C-x C-f C-p.
> That doesn't work; C-p was intended to get the previous filename
> but gives 'beginning of buffer'.  You need to type M-p instead.
>
> However, in GNU bash, the situation is reversed.  To get the previous
> command line you have to hit C-p, and M-p just enters a control
> sequence.  So there is a user interface inconsistency between
> bash and Emacs.

Indeed.  I also noticed this inconsistency time ago.

> I think the best way to resolve it is to make C-p and C-n work in
> the Emacs minibuffer to get the previous and next lines from the
> history, just as M-p and M-n do.  Since the minibuffer is almost
> always a single line of text, the bindings to previous-line and
> next-line aren't helpful in the minibuffer.

I wonder why bash uses C-p/C-n instead of M-p/M-n for browsing the
command history.

Indeed Minibuffers have usually a single line of text, but not always.
  So, I think that the standard meaning of C-p/C-n (previous/next
line) is sometimes useful also in the minibuffer.

IOW, I'd rather change bash behavior to match the Emacs one, instead
of the other way around.

-- 
Dani Moncayo

bug#16740: 24.2; Please allow C-p and C-n in minibuffer

[Ed Avis]

>IOW, I'd rather change bash behavior to match the Emacs one, instead
>of the other way around.

I expected that to be the response.  And no doubt on the bash mailing
list it would be the opposite.  I will ask them though.  To my mind the
best resolution is for both programs to accept both keybindings.

I agree that sometimes it happens that the minibuffer contains more than
one line of text.  But never with find-file.  I don't think I've ever wanted to
create or open a filename with embedded newline using Emacs.

As a compromise could Emacs make C-p do previous-line if the minibuffer
contains more than one line, and previous-history-element otherwise?

-- 
Ed Avis <eda@waniasset.com>

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________

bug#16740: 24.2; Please allow C-p and C-n in minibuffer

[Dani Moncayo]

On Thu, Feb 13, 2014 at 12:32 PM, Ed Avis <eda@waniasset.com> wrote:
>>IOW, I'd rather change bash behavior to match the Emacs one, instead
>>of the other way around.
>
> I expected that to be the response.  And no doubt on the bash mailing
> list it would be the opposite.  I will ask them though.  To my mind the
> best resolution is for both programs to accept both keybindings.

I think that having different meanings for C-p/C-n and M-p/M-n would
give a richer user interface, also in bash, because it would allow, on
one hand to browse the command history (with M-p/M-n) while at the
same time move vertically within a single multiline command (with
C-p/C-n).  Just like in Emacs.   IMO that would be TRT.

-- 
Dani Moncayo

bug#16740: 24.2; Please allow C-p and C-n in minibuffer

[Stefan Monnier]

> I think the best way to resolve it is to make C-p and C-n work in
> the Emacs minibuffer to get the previous and next lines from the
> history, just as M-p and M-n do.

Directly binding C-p and C-n to the same commands as M-p and M-n is not
really an option, since we need the current behavior for multiline
editing (and even filenames without newlines can span multiple lines,
if the file name is ling enough to cause wrapping).

But we could make C-p/C-n jump to the previous/next history element
when called from the first/last line, which would combine both behaviors.
The implementation should be careful to make sure that C-p followed by
C-n brings you back to the same position (same for C-n followed by C-p),
otherwise such behavior can get irritating when you accidentally hit C-p
from the first line.


        Stefan

bug#16740: 24.2; Please allow C-p and C-n in minibuffer

[Ed Avis]

Stefan Monnier wrote:

>But we could make C-p/C-n jump to the previous/next history element
>when called from the first/last line,

That would work.  So where it currently prints 'Beginning of buffer' it
would instead go to the previous item in the history.  But where C-p
currently does something, its behaviour would not change.

You are right that the minibuffer can contain multiple lines just because
the filename is long enough.  I was still thinking in terms of the old days
when next-line went to the next logical line, not the next physical line
on screen.

-- 
Ed Avis <eda@waniasset.com>

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________

bug#16740: 24.2; Please allow C-p and C-n in minibuffer

[Drew Adams]

> But we could make C-p/C-n jump to the previous/next history element
> when called from the first/last line, which would combine both
> behaviors. The implementation should be careful to make sure that
> C-p followed by C-n brings you back to the same position (same for
> C-n followed by C-p), otherwise such behavior can get irritating
> when you accidentally hit C-p from the first line.

Just makes the user interaction more confusing.

In particular, in some cases it might not be obvious to a user
that s?he is at the last line, or s?he might not notice that fact.

Or s?he might intentionally hold down `C-n' or `C-p' to get to the
end or start without counting or looking after each keypress.

YAGNI.

bug#16740: 24.2; Please allow C-p and C-n in minibuffer

[Dani Moncayo]

On Thu, Feb 13, 2014 at 3:44 PM, Drew Adams <drew.adams@oracle.com> wrote:
>> But we could make C-p/C-n jump to the previous/next history element
>> when called from the first/last line, which would combine both
>> behaviors. The implementation should be careful to make sure that
>> C-p followed by C-n brings you back to the same position (same for
>> C-n followed by C-p), otherwise such behavior can get irritating
>> when you accidentally hit C-p from the first line.
>
> Just makes the user interaction more confusing.
>
> In particular, in some cases it might not be obvious to a user
> that s?he is at the last line, or s?he might not notice that fact.
>
> Or s?he might intentionally hold down `C-n' or `C-p' to get to the
> end or start without counting or looking after each keypress.
>
> YAGNI.

That's exactly what I think.

I've just filed a request to the Bash developers (bug-bash@gnu.org)
about this [1].  Let's see what they say...


--- footnotes ---

[1] But it doesn't appear yet at
http://lists.gnu.org/archive/html/bug-bash/2014-02/index.html

-- 
Dani Moncayo

bug#16740: 24.2; Please allow C-p and C-n in minibuffer

[Stefan Monnier]

>> But we could make C-p/C-n jump to the previous/next history element
>> when called from the first/last line, which would combine both
>> behaviors. The implementation should be careful to make sure that
>> C-p followed by C-n brings you back to the same position (same for
>> C-n followed by C-p), otherwise such behavior can get irritating
>> when you accidentally hit C-p from the first line.
> Just makes the user interaction more confusing.

I wouldn't like it, indeed, and I don't think it would make sense as
a default.  But an option could provide that behavior.


        Stefan

bug#16740: 24.2; Please allow C-p and C-n in minibuffer

[Stefan Kangas]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> But we could make C-p/C-n jump to the previous/next history element
>>> when called from the first/last line, which would combine both
>>> behaviors. The implementation should be careful to make sure that
>>> C-p followed by C-n brings you back to the same position (same for
>>> C-n followed by C-p), otherwise such behavior can get irritating
>>> when you accidentally hit C-p from the first line.
>> Just makes the user interaction more confusing.
>
> I wouldn't like it, indeed, and I don't think it would make sense as
> a default.  But an option could provide that behavior.

No one has implemented this in 8 years, so I'm leaning towards closing
this feature request.  If anyone thinks it should remain open, please
speak up.  Thanks.

bug#16740: 24.2; Please allow C-p and C-n in minibuffer

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Stefan Kangas <stefan@marxist.se> writes:

>> I wouldn't like it, indeed, and I don't think it would make sense as
>> a default.  But an option could provide that behavior.

> No one has implemented this in 8 years, so I'm leaning towards closing
> this feature request.  If anyone thinks it should remain open, please
> speak up.  Thanks.

It should stay open, because it would be a pretty nice feature.  I tend
to think that feature should not be the default, however.

I might implement this soon at some point.

bug#16740: 24.2; Please allow C-p and C-n in minibuffer

[Juri Linkov]

>>>> But we could make C-p/C-n jump to the previous/next history element
>>>> when called from the first/last line, which would combine both
>>>> behaviors. The implementation should be careful to make sure that
>>>> C-p followed by C-n brings you back to the same position (same for
>>>> C-n followed by C-p), otherwise such behavior can get irritating
>>>> when you accidentally hit C-p from the first line.
>>> Just makes the user interaction more confusing.
>>
>> I wouldn't like it, indeed, and I don't think it would make sense as
>> a default.  But an option could provide that behavior.
>
> No one has implemented this in 8 years, so I'm leaning towards closing
> this feature request.  If anyone thinks it should remain open, please
> speak up.  Thanks.

This feature was implemented in the same year when requested.

bug#16740: 24.2; Please allow C-p and C-n in minibuffer

[Stefan Kangas]

Juri Linkov <juri@linkov.net> writes:

> This feature was implemented in the same year when requested.

So this feature request could be closed?

bug#16740: 24.2; Please allow C-p and C-n in minibuffer

[Juri Linkov]

>> This feature was implemented in the same year when requested.
>
> So this feature request could be closed?

Before closing, we need to decide whether to bind C-p and C-n
to the same commands that were bound in 2014 to [up] and [down],
i.e. whether to apply such patch:

diff --git a/lisp/bindings.el b/lisp/bindings.el
index f70a9efe41..b11872c84e 100644
--- a/lisp/bindings.el
+++ b/lisp/bindings.el
@@ -1028,10 +1028,12 @@ global-map
   (define-key map "\en"   'next-history-element)
   (define-key map [next]  'next-history-element)
   (define-key map [down]  'next-line-or-history-element)
+  (define-key map "\C-n"  'next-line-or-history-element)
   (define-key map [XF86Forward] 'next-history-element)
   (define-key map "\ep"   'previous-history-element)
   (define-key map [prior] 'previous-history-element)
   (define-key map [up]    'previous-line-or-history-element)
+  (define-key map "\C-p"  'previous-line-or-history-element)
   (define-key map [XF86Back] 'previous-history-element)
   (define-key map "\es"   'next-matching-history-element)
   (define-key map "\er"   'previous-matching-history-element)

bug#16740: 24.2; Please allow C-p and C-n in minibuffer

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> Before closing, we need to decide whether to bind C-p and C-n
> to the same commands that were bound in 2014 to [up] and [down],
> i.e. whether to apply such patch:

[...]

>    (define-key map [down]  'next-line-or-history-element)
> +  (define-key map "\C-n"  'next-line-or-history-element)

If I remember correctly, I think the idea was to have a way for the user
to skip the nice magical DWIM stuff that's on up/down, so C-n/C-p was
left alone on purpose.  And I think that's still the right decision.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#16740: 24.2; Please allow C-p and C-n in minibuffer

[Juri Linkov]

>> Before closing, we need to decide whether to bind C-p and C-n
>> to the same commands that were bound in 2014 to [up] and [down],
>> i.e. whether to apply such patch:
> [...]
>>    (define-key map [down]  'next-line-or-history-element)
>> +  (define-key map "\C-n"  'next-line-or-history-element)
>
> If I remember correctly, I think the idea was to have a way for the user
> to skip the nice magical DWIM stuff that's on up/down, so C-n/C-p was
> left alone on purpose.  And I think that's still the right decision.

This was my recollection too.  So if no one has new arguments
to change this decision, this request could be closed.

bug#16740: 24.2; Please allow C-p and C-n in minibuffer

[Stefan Kangas]

Juri Linkov <juri@linkov.net> writes:

>>> Before closing, we need to decide whether to bind C-p and C-n
>>> to the same commands that were bound in 2014 to [up] and [down],
>>> i.e. whether to apply such patch:
>> [...]
>>>    (define-key map [down]  'next-line-or-history-element)
>>> +  (define-key map "\C-n"  'next-line-or-history-element)
>>
>> If I remember correctly, I think the idea was to have a way for the user
>> to skip the nice magical DWIM stuff that's on up/down, so C-n/C-p was
>> left alone on purpose.  And I think that's still the right decision.
>
> This was my recollection too.  So if no one has new arguments
> to change this decision, this request could be closed.

OK, closing.