bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: David De La Harpe Golden
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
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.20) Gecko/20110820 Icedove/3.1.12

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)





reply via email to

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