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

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

[Dani Moncayo]

Package: emacs
Severity: wishlist

As all of you know, if you want to yank into a buffer some entry from
the kill ring (which is not the last one), you have to yank the first
entry (C-y) and then look for the right one by typing M-y repeatedly.

IMO, this way of navigating through the kill ring has two problems:
1. Is not intuitive: the standard way of "history searching" is with
M-p/M-n (Search ring, minibuffer input, ...).
2. Is cumbersome in some cases: If you repeat `M-y' quickly to find an
old entry and realize that the wanted entry was already retrieved, you
have to invoke a negative prefix argument and then `M-y'.  Pretty
cumbersome.

Therefore, my proposal is obvious: Just after yanking some text into
some buffer (and before doing anything else) the keys M-p/M-n should
allow the user to navigate (backward/forward) through the kill ring.
The selected entry would be placed in the buffer (as happens now with
M-y).


-- 
Dani Moncayo

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

[Juri Linkov]

> Therefore, my proposal is obvious: Just after yanking some text into
> some buffer (and before doing anything else) the keys M-p/M-n should
> allow the user to navigate (backward/forward) through the kill ring.
> The selected entry would be placed in the buffer (as happens now with
> M-y).

This is implemented in
http://lists.gnu.org/archive/html/emacs-devel/2010-03/msg01176.html
where after M-y you can use M-p/M-n to navigate through the kill ring.

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

[Dani Moncayo]

Hi Juri,

> This is implemented in
> http://lists.gnu.org/archive/html/emacs-devel/2010-03/msg01176.html
> where after M-y you can use M-p/M-n to navigate through the kill ring.

I see, but why we should type M-y at all?  I would like to type
M-p/M-n just after C-y.

-- 
Dani Moncayo

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

[Juri Linkov]

>> This is implemented in
>> http://lists.gnu.org/archive/html/emacs-devel/2010-03/msg01176.html
>> where after M-y you can use M-p/M-n to navigate through the kill ring.
>
> I see, but why we should type M-y at all?  I would like to type
> M-p/M-n just after C-y.

Yes, this would be good.  So it could work exactly like `C-s M-p'
in Isearch mode where `M-p' activates the minibuffer.  `C-y M-p'
could do the same.

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

[Deniz Dogan]

On 2011-08-30 14:27, Juri Linkov wrote:
>>> This is implemented in
>>> http://lists.gnu.org/archive/html/emacs-devel/2010-03/msg01176.html
>>> where after M-y you can use M-p/M-n to navigate through the kill ring.
>>
>> I see, but why we should type M-y at all?  I would like to type
>> M-p/M-n just after C-y.
>
> Yes, this would be good.  So it could work exactly like `C-s M-p'
> in Isearch mode where `M-p' activates the minibuffer.  `C-y M-p'
> could do the same.
>

I strongly oppose it.  I've used M-n and M-p for forward-paragraph and 
backward-paragraph for years and I'm sure many other people use them for 
other things too.  Please, leave M-n and M-p for other things than 
browsing the kill ring in this manner.  There is already many different 
ways to do this, all on the Emacs Wiki.[1]

Deniz

[1]: http://www.emacswiki.org/cgi-bin/wiki?BrowseKillRing

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

[Dani Moncayo]

Hi Deniz,

On Tue, Aug 30, 2011 at 20:13, Deniz Dogan <deniz@dogan.se> wrote:
> I strongly oppose it.  I've used M-n and M-p for forward-paragraph and
> backward-paragraph for years and I'm sure many other people use them for
> other things too.  Please, leave M-n and M-p for other things than browsing
> the kill ring in this manner.

You (and many others) could still use M-n and M-p for whatever you
want, because my proposal would only affect that keys *just after
typing C-y, and before doing anything else*.

> There is already many different ways to do
> this, all on the Emacs Wiki.[1]

I'm interested in improving the standard GNU Emacs, and the current
way of navigating through the kill ring is not very convenient, as I
explained.  My proposal would greatly improve it without harming
anyone (IMO).

-- 
Dani Moncayo

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

[Dani Moncayo]

Hi Juri,

On Tue, Aug 30, 2011 at 14:27, Juri Linkov <juri@jurta.org> wrote:
> Yes, this would be good.  So it could work exactly like `C-s M-p'
> in Isearch mode where `M-p' activates the minibuffer.  `C-y M-p'
> could do the same.

Using the minibuffer would be indeed a way of doing this, but on
second thought I think that it would be better to have "in-site"
replacement of the yanked text (like M-y does now), because:

1. It would be quicker: It saves you the extra <RET> once you have
selected the wanted entry.

2. When the killed text is tall (has many lines), the minibuffer would
show only a small fragment of it.

Thus, for example if you wanted to yank the third entry from the kill
ring, all you would have to to is "C-y M-p M-p M-p" and you're done.
Very quick, very intuitive, very convenient!

I'm not an expert in Emacs' internals, but I think that one way of
implementing this would be as a minor mode, that would be activated by
C-y (like Isearch is activated by C-s), and deactivated by "anything
else" (distinct from M-p M-n and M-y*).

(*) The behavior of M-y would remain the same, obviously, for old-timers.

-- 
Dani Moncayo

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

[Juri Linkov]

> Using the minibuffer would be indeed a way of doing this, but on
> second thought I think that it would be better to have "in-site"
> replacement of the yanked text (like M-y does now), because:
>
> 1. It would be quicker: It saves you the extra <RET> once you have
> selected the wanted entry.

"In-situ" replacement is quicker indeed but has its own problems:
to undo the last yanked text to the initial state you have to undo
insertions and deletions of all intermediate elements of the kill ring.

So what you propose is like setting `search-ring-update' to t in Isearch.
It's quicker without requiring <RET>, but to revert to the initial search
position you have to undo all search movements for intermediate elements of
the search ring.

> 2. When the killed text is tall (has many lines), the minibuffer would
> show only a small fragment of it.

The minibuffer shows enough multi-line text to recognize the wanted entry.

> Thus, for example if you wanted to yank the third entry from the kill
> ring, all you would have to to is "C-y M-p M-p M-p" and you're done.
> Very quick, very intuitive, very convenient!

With many M-p, one extra <RET> is not a problem.

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

[Dani Moncayo]

Hi Juri,

On Wed, Aug 31, 2011 at 11:51, Juri Linkov <juri@jurta.org> wrote:
>> Using the minibuffer would be indeed a way of doing this, but on
>> second thought I think that it would be better to have "in-site"
>> replacement of the yanked text (like M-y does now), because:
>>
>> 1. It would be quicker: It saves you the extra <RET> once you have
>> selected the wanted entry.
>
> "In-situ" replacement is quicker indeed but has its own problems:
> to undo the last yanked text to the initial state you have to undo
> insertions and deletions of all intermediate elements of the kill ring.
>
> So what you propose is like setting `search-ring-update' to t in Isearch.
> It's quicker without requiring <RET>, but to revert to the initial search
> position you have to undo all search movements for intermediate elements of
> the search ring.

Correct.  That is the way M-y works now, so that this would not be a
new problem.  Besides, that problem is quite minor, IMO, because:
* The common case would be to yank the last or close-to-last entry
from the ring, so that no (or very few) extra "undo" movements would
be necessary.
* In the rare cases of yanking and old entry *and* then wanting to
revert it, users would always have the quick option of deleting the
region (which as you now is updated in every yank operation).

So, i think that the drawbacks are much smaller than the advantages.

>> 2. When the killed text is tall (has many lines), the minibuffer would
>> show only a small fragment of it.
>
> The minibuffer shows enough multi-line text to recognize the wanted entry.

Yes, I also think so.  So this point would make little difference, but
anyway large entries would be shown even better in the buffer, because
there would be normally more visual space.

>> Thus, for example if you wanted to yank the third entry from the kill
>> ring, all you would have to to is "C-y M-p M-p M-p" and you're done.
>> Very quick, very intuitive, very convenient!
>
> With many M-p, one extra <RET> is not a problem.

As I've said above, I think that the common case would imply one or
very few "M-p"'s.  Besides, typing 2 or 3 times the same key is almost
as quick as typing it only once.  Therefore, IMO the extra <RET> would
really make a difference.

-- 
Dani Moncayo

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

[Stefan Monnier]

Basically it would amount to moving the M-y binding to M-p but only if
used immediately after C-y, and to add a M-n binding to the same command
but that cycles in the other direction.

That doesn't sound like a bad idea, although of course it will annoy
a few users in a few corner cases (e.g. I have M-n and M-p bound in
smerge-mode).  So we might prefer to have it as an option.

> I'm not an expert in Emacs' internals, but I think that one way of
> implementing this would be as a minor mode, that would be activated by
> C-y (like Isearch is activated by C-s), and deactivated by "anything
> else" (distinct from M-p M-n and M-y*).

I use the function below to do these kinds of things.  I didn't find the
time to install it for Emacs-24.1, tho.
You should be able to get this working fairly cleanly with an
after-advice on `yank' which uses that set-temporary-overlay-map.

> (*) The behavior of M-y would remain the same, obviously, for old-timers.

Actually one of the benefits of your proposal is that it opens up the
possibility of freeing the M-y binding.


        Stefan


(defun set-temporary-overlay-map (map &optional keep-pred)
  (let* ((clearfunsym (make-symbol "clear-temporary-overlay-map"))
         (overlaysym (make-symbol "t"))
         (alist (list (cons overlaysym map)))
         (clearfun
          ;; FIXME: Use lexical-binding.
          `(lambda ()
             (unless ,(cond ((null keep-pred) nil)
                            ((eq t keep-pred)
                             `(eq this-command
                                  (lookup-key ',map
                                              (this-command-keys-vector))))
                            (t `(funcall ',keep-pred)))
               (remove-hook 'pre-command-hook ',clearfunsym)
               (setq emulation-mode-map-alists
                     (delq ',alist emulation-mode-map-alists))))))
    (set overlaysym overlaysym)
    (fset clearfunsym clearfun)
    (add-hook 'pre-command-hook clearfunsym)
    ;; FIXME: That's the keymaps with highest precedence, except for
    ;; the `keymap' text-property ;-(
    (push alist emulation-mode-map-alists)))

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

[Deniz Dogan]

On 2011-08-31 15:01, Stefan Monnier wrote:
> Actually one of the benefits of your proposal is that it opens up the
> possibility of freeing the M-y binding.
>

Why "free" the M-y binding if it means jailing M-n and M-p?  M-y does 
nothing useful unless preceded by C-y today, so in that sense it's 
already "free".

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

[Thierry Volpiatto]

Deniz Dogan <deniz@dogan.se> writes:

> On 2011-08-31 15:01, Stefan Monnier wrote:
>> Actually one of the benefits of your proposal is that it opens up the
>> possibility of freeing the M-y binding.
>>
>
> Why "free" the M-y binding if it means jailing M-n and M-p?  M-y does
> nothing useful unless preceded by C-y today, so in that sense it's
> already "free".

It's so convenient to have a kill-ring browser, i don't understand why
emacs have not one and continue cycling blindly to find something in
kill-ring...

-- 
A+ Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

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

[Deniz Dogan]

On 2011-08-31 16:33, Thierry Volpiatto wrote:
> Deniz Dogan<deniz@dogan.se>  writes:
>
>> On 2011-08-31 15:01, Stefan Monnier wrote:
>>> Actually one of the benefits of your proposal is that it opens up the
>>> possibility of freeing the M-y binding.
>>>
>>
>> Why "free" the M-y binding if it means jailing M-n and M-p?  M-y does
>> nothing useful unless preceded by C-y today, so in that sense it's
>> already "free".
>
> It's so convenient to have a kill-ring browser, i don't understand why
> emacs have not one and continue cycling blindly to find something in
> kill-ring...
>

It's still much better than any other text editor I know of.  And either 
way, there are already third-party alternatives if the Emacs defaults 
isn't good enough.

I think it would be better if we rebind M-y completely to enter a new 
mode which browses the kill ring in the minibuffer.  But leave C-y alone.

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

[Stefan Monnier]

>> Why "free" the M-y binding if it means jailing M-n and M-p?

You didn't read me right: I only pointed out that *if/when* M-p/M-n is
used as suggested, then M-y can be freed.

>> M-y does nothing useful unless preceded by C-y today, so in that
>> sense it's already "free".

That's true, except that the current implementation occupies the M-y
binding all the time.

> It's so convenient to have a kill-ring browser, i don't understand why
> Emacs have not one and continue cycling blindly to find something in
> kill-ring...

It's already been suggested, and I agree it's a good idea.
I.e. patches welcome for Emacs-24.2.  But most likely I'd only accept
such a patch if the "kill-ring browser" uses a more-or-less standard
"minibuffer with completion".  OTOH it'd be OK for that patch to include
some changes to minibuffer.el, if needed.  FWIW, here's the code I'm
using right now.


        Stefan


(defun yank-browse (string)
  "Browse the `kill-ring' to choose which entry to yank."
  (interactive
   (minibuffer-with-setup-hook #'minibuffer-completion-help
     (let* ((kills (delete-dups (append kill-ring-yank-pointer kill-ring nil)))
            (entries
             (mapcar (lambda (string)
                       (let ((pos 0))
                         ;; FIXME: Maybe we should start by removing
                         ;; all properties.
                         (setq string (copy-sequence string))
                         (while (string-match "\n" string pos)
                           ;; FIXME: Maybe completion--insert-strings should
                           ;; do that for us.
                           (put-text-property
                            (match-beginning 0) (match-end 0)
                            'display (eval-when-compile
                                       (propertize "\\n" 'face 'escape-glyph))
                            string)
                           (setq pos (match-end 0)))
                         ;; FIXME: We may use the window-width of the
                         ;; wrong window.
                         (when (>= (* 3 (string-width string))
                                   (* 2 (window-width)))
                           (let ((half (- (/ (window-width) 3) 1)))
                             ;; FIXME: We're using char-counts rather than
                             ;; width-count.
                             (put-text-property
                              half (- (length string) half)
                              'display (eval-when-compile
                                         (propertize "……" 'face 'escape-glyph))
                              string)))
                         string))
                     kills))
            (table (lambda (string pred action)
                     (cond
                      ((eq action 'metadata)
                       '(metadata (category . kill-ring)))
                      (t
                       (complete-with-action action entries string pred))))))
       ;; FIXME: We should return the entry from the kill-ring rather than
       ;; the entry from the completion-table.
       ;; FIXME: substring completion doesn't work well because it only matches
       ;; subtrings before the first \n.
       ;; FIXME: completion--insert-strings assumes that boundaries of
       ;; candidates are obvious enough, but with kill-ring entries this is not
       ;; true, so we'd probably want to display them with «...» around them.
       (list (completing-read "Yank: " table nil t)))))
  (setq this-command 'yank)
  (insert-for-yank string))

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

[Dani Moncayo]

On Wed, Aug 31, 2011 at 15:55, Deniz Dogan <deniz@dogan.se> wrote:
> On 2011-08-31 15:01, Stefan Monnier wrote:
>>
>> Actually one of the benefits of your proposal is that it opens up the
>> possibility of freeing the M-y binding.
>>
>
> Why "free" the M-y binding if it means jailing M-n and M-p?

M-n and M-p would not be jailed at all, as I've tried to explain to
you several times.  They would remain unbound, as now.  The only
exception would be after typing C-y...

> M-y does nothing useful unless preceded by C-y today, so in that sense it's already
> "free".

If you do "C-h c M-y", you will see that M-y is not currently free.


-- 
Dani Moncayo

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

[Deniz Dogan]

On 2011-08-31 17:40, Dani Moncayo wrote:
> On Wed, Aug 31, 2011 at 15:55, Deniz Dogan<deniz@dogan.se>  wrote:
>> On 2011-08-31 15:01, Stefan Monnier wrote:
>>>
>>> Actually one of the benefits of your proposal is that it opens up the
>>> possibility of freeing the M-y binding.
>>>
>>
>> Why "free" the M-y binding if it means jailing M-n and M-p?
>
> M-n and M-p would not be jailed at all, as I've tried to explain to
> you several times.  They would remain unbound, as now.  The only
> exception would be after typing C-y...
>

I understand that.

So what we have today is: "M-y is free unless preceded by C-y."  What 
you propose is: "M-n and M-p are free unless preceded by C-y."  However, 
the way Stefan put it makes it sound like we're freeing up key bindings 
here.  We're not.

>>   M-y does nothing useful unless preceded by C-y today, so in that sense it's already
>> "free".
>
> If you do "C-h c M-y", you will see that M-y is not currently free.
>

As I said, M-y does nothing useful unless preceded by C-y.  In other 
words, the command is useless unless you do C-y first.  This is why I 
propose that the behavior of M-y is changed so that unless it is 
preceded by C-y, it enters a new mode which browses the kill-ring with 
M-n and M-p.

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

[Drew Adams]

> If you do "C-h c M-y", you will see that M-y is not currently free.

Which is unfortunate, since if M-y is not preceded by a yank then you just get a
message stating that fact.  Not much use as a global binding.

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

[Dani Moncayo]

> Basically it would amount to moving the M-y binding to M-p but only if
> used immediately after C-y, and to add a M-n binding to the same command
> but that cycles in the other direction.
>
> That doesn't sound like a bad idea, although of course it will annoy
> a few users in a few corner cases (e.g. I have M-n and M-p bound in
> smerge-mode).  So we might prefer to have it as an option.

I think that those corner cases are pretty few (How often you will be
using M-p/M-n just after C-y?), but if you deem it necessary, ok.

>> I'm not an expert in Emacs' internals, but I think that one way of
>> implementing this would be as a minor mode, that would be activated by
>> C-y (like Isearch is activated by C-s), and deactivated by "anything
>> else" (distinct from M-p M-n and M-y*).
>
> I use the function below to do these kinds of things.  I didn't find the
> time to install it for Emacs-24.1, tho.
> You should be able to get this working fairly cleanly with an
> after-advice on `yank' which uses that set-temporary-overlay-map.

Thanks.  I'm still beginning to learn Elisp, so right now I would not
be able to work it out.

>> (*) The behavior of M-y would remain the same, obviously, for old-timers.
>
> Actually one of the benefits of your proposal is that it opens up the
> possibility of freeing the M-y binding.

I just wanted to make the change as smooth as possible, but of course
the current behavior of M-y would be adopted by M-p, so M-y could be
freed or used for anything else.  I'm perfectly fine with that,
because I would obviously use M-p, not M-y.


-- 
Dani Moncayo

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

[David De La Harpe Golden]

On 31/08/11 14:01, Stefan Monnier wrote:
 > That doesn't sound like a bad idea, although of course it will annoy
 > a few users in a few corner cases (e.g. I have M-n and M-p bound in
 > smerge-mode).  So we might prefer to have it as an option.

I definitely do use various modes with M-n/M-p already bound (such as 
slime), they're often some "mode appropriate next/previous".  I expect I 
do hit them directly after a C-y sometimes too, though I suppose
in principle I could get used to not being able to (and I'm not exactly 
a new user who doesn't know how to alter bindings anyway...)

All the same, one alternative would be M-y and M-C-y after C-y for 
moving in opposite directions through the kill ring? Just tried it and 
it doesn't feel too bad to me, anyway.

(defun yank-pop-inv (&optional arg)
   (interactive "*p")
   (unless arg (setq arg 1))
   (let ((arg (- arg)))
     (yank-pop arg)))

(global-set-key (kbd "M-C-y") #'yank-pop-inv)


OTOH, "kill-ring-search" tends to be more useful than uni- or bi- 
directional navigation through the kill ring. The author suggests M-C-y 
as its default binding:
http://nschum.de/src/emacs/kill-ring-search/

So I'd also consider, given M-y is currently globally bound to a 
definition that isn't used except after C-y, putting kill-ring-search 
functionality on M-y when _not_ after C-y.

Then also add a kill-ring-search-next to the kill-ring-search prompt as 
M-C-y (it already has a kill-ring-search-prev on M-y).

That would also actually sort of fit in with C-y followed by M-y / M-C-y 
as suggested earlier above, as then C-y followed by M-y / M-C-y could be 
considered to be acting like the new M-y, with a null search string, 
inplace display, and implicit exit (while still also acting just like 
C-y M-y today!).

And could add M-n and M-p to the new M-y prompt where they'd feel 
"right", without having them have an effect after C-y (or with if 
preferred, of course).

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

[Juri Linkov]

> Then also add a kill-ring-search-next to the kill-ring-search prompt as
> M-C-y (it already has a kill-ring-search-prev on M-y).

We already have a well-known user interface to browse, search and complete
items of a history list (including the kill-ring and the search-ring) in
the minibuffer with `read-from-minibuffer'.  This is better than inventing
a new user interface.

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

[Dani Moncayo]

Well, thus far the main objections to my initial proposal are:

1. Some prefer to select the kill-ring entry from the minibuffer,
which would allow "clean browsing" (i.e. without altering the undo
history), searching and completion.  I obviously agree that this would
be a nice feature.

2. Some don't want M-p/M-n to be temporally rebound after C-y.

------------

Solution for #1: Since the current M-y functionality would go to M-p,
M-y would be free and we could use it for jumping to the minibuffer.

Something similar has been proposed, but I don't want to overload M-y
with two different tasks, but instead moving the current one to M-p
(it makes a lot more sense there) and giving it the new one (it feels
quite good too: C-y for "yanking in situ" and M-y for "yanking via
minibuffer").

Solution for #2: As Stefan pointed out, that temporal rebinding of
M-p/M-n could be optional.

I think/hope that, with these additions, everyone shall be happy, and
I guess that we all agree in that this would mean a great boost in
Emacs kill-ring functionality.

WDYT?

-- 
Dani Moncayo

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

[Juri Linkov]

> WDYT?

I think we should not change the traditional behavior of `C-y M-y M-y ...'
that many users are accustomed to.  What we could do is to activate the
minibuffer browsing the kill-ring on `M-y' (not preceded by `C-y').
And optionally bind `M-p'/`M-n' after `C-y' to more transient version
of the current `M-y' that doesn't require multiple undo (but still
you have to undo the first yank inserted by `C-y').

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

[Dani Moncayo]

On Thu, Sep 1, 2011 at 10:42, Juri Linkov <juri@jurta.org> wrote:
>> WDYT?
>
> I think we should not change the traditional behavior of `C-y M-y M-y ...'
> that many users are accustomed to.

Sorry to hear that.  I agree that it is good to keep the traditional
behavior as much as possible, but not at the expense of evolving
positively.

> What we could do is to activate the
> minibuffer browsing the kill-ring on `M-y' (not preceded by `C-y').

So you want to keep the current behavior of "C-y M-y" for the sake of
"traditional behavior", so that M-y would do one thing when preceded
by C-y, and another one (completely different) when not.  IMO, this
mixing/overloading of functionality in M-y is not clean, and besides,
one of those two tasks would be already implemented in M-p.  I'd like
you to reconsider this, please.

> And optionally bind `M-p'/`M-n' after `C-y' to more transient version
> of the current `M-y' that doesn't require multiple undo (but still
> you have to undo the first yank inserted by `C-y').

100% agreement on that (I like your "transient version" improvement).


-- 
Dani Moncayo

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

[Antoine Levitt]

01/09/11 11:13, Dani Moncayo
> On Thu, Sep 1, 2011 at 10:42, Juri Linkov <juri@jurta.org> wrote:
>>> WDYT?
>>
>> I think we should not change the traditional behavior of `C-y M-y M-y ...'
>> that many users are accustomed to.
>
> Sorry to hear that.  I agree that it is good to keep the traditional
> behavior as much as possible, but not at the expense of evolving
> positively.
>
>> What we could do is to activate the
>> minibuffer browsing the kill-ring on `M-y' (not preceded by `C-y').
>
> So you want to keep the current behavior of "C-y M-y" for the sake of
> "traditional behavior", so that M-y would do one thing when preceded
> by C-y, and another one (completely different) when not.  IMO, this
> mixing/overloading of functionality in M-y is not clean, and besides,
> one of those two tasks would be already implemented in M-p.  I'd like
> you to reconsider this, please.
>
>> And optionally bind `M-p'/`M-n' after `C-y' to more transient version
>> of the current `M-y' that doesn't require multiple undo (but still
>> you have to undo the first yank inserted by `C-y').
>
> 100% agreement on that (I like your "transient version" improvement).

What about the following UI?

M-y triggers a kind of kill-ring browsing: it opens a small buffer above
the minibuffer with the next killed text (that which would be inserted
by C-y), accessible with M-y or M-n. If the user presses M-y or M-n, the
buffer expands to display the previous killed text as well, accessible
with M-p. In any event, pressing RET inserts the current killed text to
the buffer, and pressing anything other than RET/M-y/M-n/M-p kills the
buffer and resumes normal editing.

C-y M-y directly jumps to the second step of the above, but inserts
automatically the current killed text, preserving backwards
compatibility.

Therefore, C-y M-y M-y ... does the right thing, with the added
convenience of a buffer allowing you to go back to a previous
completion. Also M-y becomes a nice alias for viewing the kill-ring.

This has the merit of not binding M-n / M-p in anything else than the
mode this buffer would be displayed in. Doing it any other way would
probably cause confusion to users/modes who bind M-n/M-p.

The appearance of the small window would be controllable with a boolean
setting.

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

[Dani Moncayo]

On Thu, Sep 1, 2011 at 11:53, Antoine Levitt <antoine.levitt@gmail.com> wrote:
> What about the following UI?


Quotation from a Juri's post:

On Wed, Aug 31, 2011 at 18:36, Juri Linkov <juri@jurta.org> wrote:
> We already have a well-known user interface to browse, search and complete
> items of a history list (including the kill-ring and the search-ring) in
> the minibuffer with `read-from-minibuffer'.  This is better than inventing
> a new user interface.


So please, let's focus on realistic proposals.

-- 
Dani Moncayo

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

[Juri Linkov]

> So you want to keep the current behavior of "C-y M-y" for the sake of
> "traditional behavior", so that M-y would do one thing when preceded
> by C-y, and another one (completely different) when not.

There are many commands that work differently when preceded by another
key like e.g. `C-u'.  So there is no problem when `M-y' preceded by `C-y'
works differently.

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

[Dani Moncayo]

> There are many commands that work differently when preceded by another
> key like e.g. `C-u'.  So there is no problem when `M-y' preceded by `C-y'
> works differently.

That is not comparable: C-u is the universal-argument key, and it's
sole purpose in life is to serve as a prefix key to extend the
behavior of the others key sequences.

However C-y is not a prefix key, and the proposed behavior of M-y is
simple, well defined, and doesn't need to be extended by C-y, because
such pretended extension will be already bound to another key (M-p),
which is the natural choice.

With the "bloated" version of M-y, users would not be able to browse
the kill-ring in the minibuffer just after yanking the top entry with
C-y.  And why? Because of an unnecessary complexity in M-y.

Please, let's not make that mistake.

-- 
Dani Moncayo

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

[David De La Harpe Golden]

On 01/09/11 15:44, 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

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

[Dani Moncayo]

>> 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
(the very subject of this feature request, remember?).  Therefore, M-y
could be used entirely for a brand new task.


-- 
Dani Moncayo

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

[David De La Harpe Golden]

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)

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

[Lars Ingebrigtsen]

Juri Linkov <juri@jurta.org> writes:

>> Therefore, my proposal is obvious: Just after yanking some text into
>> some buffer (and before doing anything else) the keys M-p/M-n should
>> allow the user to navigate (backward/forward) through the kill ring.
>> The selected entry would be placed in the buffer (as happens now with
>> M-y).
>
> This is implemented in
> http://lists.gnu.org/archive/html/emacs-devel/2010-03/msg01176.html
> where after M-y you can use M-p/M-n to navigate through the kill ring.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

Juri's change was adopted (I just found out about it now -- I've never
noticed it before 🙃), but there was then further discussion about
binding `M-p'/`M-n' after `C-y'.  There wasn't much enthusiasm for that,
and I think that it sounds pretty confusing myself, so I'm therefore
closing this bug report.

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