GNU bug report logs - #9406
24.0.50; Use M-p/M-n to navigate through the kill ring

Previous Next

Full log

View this message in rfc822 format

From: David De La Harpe Golden <david <at> harpegolden.net>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: Juri Linkov <juri <at> jurta.org>, Deniz Dogan <deniz <at> dogan.se>, Stefan Monnier <monnier <at> iro.umontreal.ca>, 9406 <at> debbugs.gnu.org
Subject: bug#9406: 24.0.50; Use M-p/M-n to navigate through the kill ring
Date: Fri, 02 Sep 2011 02:24:07 +0100

On 01/09/11 22:56, Dani Moncayo wrote:
>>> users would not be able to browse
>>> the kill-ring in the minibuffer just after yanking the top entry with
>>> C-y.
>>
>> They are browsing it in-place with M-y
>
> In-place browsing would be already doable in a more convenient way

While default behaviour of M-y is obviously wastefully useless without 
the preceding C-y, default behaviour of C-y M-y is long-standing [1].
While (cough) I am not exactly one to balk at a change to a 
long-standing default just because it's long-standing (and hey it's not 
at all up to me anyway, Stefan's already been pretty positive), you do 
just have to expect some people to think an idea to change such a 
long-standing default is not quite as great as you may think it is.

"More convenient" is also somewhat subjective - for one thing, if M-y's 
present behaviour after C-y is gone and you have to use M-n/M-p instead, 
you have to switch from y to n/p (even when touch typing properly, n is 
on the same finger as y on qwerty), whereas you do get to stay on y for 
M-y/M-C-y, and of course (as already mentioned) you can't press M-n/M-p 
for their normal functionality in some mode directly after a C-y anymore.

Presumably, the latter would just mean learning to hit C-g after C-y if 
you're about to press M-n to go to the next slime compiler note or 
whatever, so (as already mentioned) I do not actually strongly object to 
special meaning of M-n/M-p after C-y, so long as M-n/M-p are not 
globally bound even without a preceding C-y (a global binding would 
discourage the IMO pleasant current "mode-appropriate next/prev" common 
usage, as ISTR being mentioned under another different recent proposal 
for an M-n/M-p binding on emacs-devel). Still I suspect you just happen 
to not already use M-n/M-p nearly as much as some people like myself.

[1]

http://bzr.savannah.gnu.org/lh/emacs/trunk/annotate/476/lisp/simple.el#L768
http://bzr.savannah.gnu.org/lh/emacs/trunk/annotate/476/lisp/simple.el#L1630

(and it was presumably there before that date, rev 476 is just when 
simple.el got imported into version control, at least the version 
control that our present history has a lineage all the way back to)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.