all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#9406: 24.0.50; Use M-p/M-n to navigate through the kill ring
@ 2011-08-30 11:39 Dani Moncayo
  2011-08-30 12:08 ` Juri Linkov
  0 siblings, 1 reply; 31+ messages in thread
From: Dani Moncayo @ 2011-08-30 11:39 UTC (permalink / raw)
  To: 9406

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





^ permalink raw reply	[flat|nested] 31+ messages in thread

* bug#9406: 24.0.50; Use M-p/M-n to navigate through the kill ring
  2011-08-30 11:39 bug#9406: 24.0.50; Use M-p/M-n to navigate through the kill ring Dani Moncayo
@ 2011-08-30 12:08 ` Juri Linkov
  2011-08-30 12:17   ` Dani Moncayo
  2022-04-27 14:21   ` Lars Ingebrigtsen
  0 siblings, 2 replies; 31+ messages in thread
From: Juri Linkov @ 2011-08-30 12:08 UTC (permalink / raw)
  To: Dani Moncayo; +Cc: 9406

> 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.





^ permalink raw reply	[flat|nested] 31+ messages in thread

* bug#9406: 24.0.50; Use M-p/M-n to navigate through the kill ring
  2011-08-30 12:08 ` Juri Linkov
@ 2011-08-30 12:17   ` Dani Moncayo
  2011-08-30 12:27     ` Juri Linkov
  2022-04-27 14:21   ` Lars Ingebrigtsen
  1 sibling, 1 reply; 31+ messages in thread
From: Dani Moncayo @ 2011-08-30 12:17 UTC (permalink / raw)
  To: Juri Linkov; +Cc: 9406

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





^ permalink raw reply	[flat|nested] 31+ messages in thread

* bug#9406: 24.0.50; Use M-p/M-n to navigate through the kill ring
  2011-08-30 12:17   ` Dani Moncayo
@ 2011-08-30 12:27     ` Juri Linkov
  2011-08-30 18:13       ` Deniz Dogan
  2011-08-31  6:22       ` Dani Moncayo
  0 siblings, 2 replies; 31+ messages in thread
From: Juri Linkov @ 2011-08-30 12:27 UTC (permalink / raw)
  To: Dani Moncayo; +Cc: 9406

>> 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.





^ permalink raw reply	[flat|nested] 31+ messages in thread

* bug#9406: 24.0.50; Use M-p/M-n to navigate through the kill ring
  2011-08-30 12:27     ` Juri Linkov
@ 2011-08-30 18:13       ` Deniz Dogan
  2011-08-30 18:48         ` Dani Moncayo
  2011-08-31  6:22       ` Dani Moncayo
  1 sibling, 1 reply; 31+ messages in thread
From: Deniz Dogan @ 2011-08-30 18:13 UTC (permalink / raw)
  To: 9406

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





^ permalink raw reply	[flat|nested] 31+ messages in thread

* bug#9406: 24.0.50; Use M-p/M-n to navigate through the kill ring
  2011-08-30 18:13       ` Deniz Dogan
@ 2011-08-30 18:48         ` Dani Moncayo
  0 siblings, 0 replies; 31+ messages in thread
From: Dani Moncayo @ 2011-08-30 18:48 UTC (permalink / raw)
  To: Deniz Dogan; +Cc: 9406

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





^ permalink raw reply	[flat|nested] 31+ messages in thread

* bug#9406: 24.0.50; Use M-p/M-n to navigate through the kill ring
  2011-08-30 12:27     ` Juri Linkov
  2011-08-30 18:13       ` Deniz Dogan
@ 2011-08-31  6:22       ` Dani Moncayo
  2011-08-31  9:51         ` Juri Linkov
  2011-08-31 13:01         ` Stefan Monnier
  1 sibling, 2 replies; 31+ messages in thread
From: Dani Moncayo @ 2011-08-31  6:22 UTC (permalink / raw)
  To: Juri Linkov; +Cc: 9406

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





^ permalink raw reply	[flat|nested] 31+ messages in thread

* bug#9406: 24.0.50; Use M-p/M-n to navigate through the kill ring
  2011-08-31  6:22       ` Dani Moncayo
@ 2011-08-31  9:51         ` Juri Linkov
  2011-08-31 10:45           ` Dani Moncayo
  2011-08-31 13:01         ` Stefan Monnier
  1 sibling, 1 reply; 31+ messages in thread
From: Juri Linkov @ 2011-08-31  9:51 UTC (permalink / raw)
  To: Dani Moncayo; +Cc: 9406

> 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.





^ permalink raw reply	[flat|nested] 31+ messages in thread

* bug#9406: 24.0.50; Use M-p/M-n to navigate through the kill ring
  2011-08-31  9:51         ` Juri Linkov
@ 2011-08-31 10:45           ` Dani Moncayo
  0 siblings, 0 replies; 31+ messages in thread
From: Dani Moncayo @ 2011-08-31 10:45 UTC (permalink / raw)
  To: Juri Linkov; +Cc: 9406

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





^ permalink raw reply	[flat|nested] 31+ messages in thread

* bug#9406: 24.0.50; Use M-p/M-n to navigate through the kill ring
  2011-08-31  6:22       ` Dani Moncayo
  2011-08-31  9:51         ` Juri Linkov
@ 2011-08-31 13:01         ` Stefan Monnier
  2011-08-31 13:55           ` Deniz Dogan
                             ` (2 more replies)
  1 sibling, 3 replies; 31+ messages in thread
From: Stefan Monnier @ 2011-08-31 13:01 UTC (permalink / raw)
  To: Dani Moncayo; +Cc: 9406

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)))





^ permalink raw reply	[flat|nested] 31+ messages in thread

* bug#9406: 24.0.50; Use M-p/M-n to navigate through the kill ring
  2011-08-31 13:01         ` Stefan Monnier
@ 2011-08-31 13:55           ` Deniz Dogan
  2011-08-31 14:33             ` Thierry Volpiatto
  2011-08-31 15:40             ` Dani Moncayo
  2011-08-31 15:33           ` Dani Moncayo
  2011-08-31 15:47           ` David De La Harpe Golden
  2 siblings, 2 replies; 31+ messages in thread
From: Deniz Dogan @ 2011-08-31 13:55 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 9406

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".





^ permalink raw reply	[flat|nested] 31+ messages in thread

* bug#9406: 24.0.50; Use M-p/M-n to navigate through the kill ring
  2011-08-31 13:55           ` Deniz Dogan
@ 2011-08-31 14:33             ` Thierry Volpiatto
  2011-08-31 14:52               ` Deniz Dogan
  2011-09-02  0:39               ` Stefan Monnier
  2011-08-31 15:40             ` Dani Moncayo
  1 sibling, 2 replies; 31+ messages in thread
From: Thierry Volpiatto @ 2011-08-31 14:33 UTC (permalink / raw)
  To: 9406

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 






^ permalink raw reply	[flat|nested] 31+ messages in thread

* bug#9406: 24.0.50; Use M-p/M-n to navigate through the kill ring
  2011-08-31 14:33             ` Thierry Volpiatto
@ 2011-08-31 14:52               ` Deniz Dogan
  2011-09-02  0:39               ` Stefan Monnier
  1 sibling, 0 replies; 31+ messages in thread
From: Deniz Dogan @ 2011-08-31 14:52 UTC (permalink / raw)
  To: Thierry Volpiatto; +Cc: 9406

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.





^ permalink raw reply	[flat|nested] 31+ messages in thread

* bug#9406: 24.0.50; Use M-p/M-n to navigate through the kill ring
  2011-08-31 13:01         ` Stefan Monnier
  2011-08-31 13:55           ` Deniz Dogan
@ 2011-08-31 15:33           ` Dani Moncayo
  2011-08-31 15:47           ` David De La Harpe Golden
  2 siblings, 0 replies; 31+ messages in thread
From: Dani Moncayo @ 2011-08-31 15:33 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 9406

> 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





^ permalink raw reply	[flat|nested] 31+ messages in thread

* bug#9406: 24.0.50; Use M-p/M-n to navigate through the kill ring
  2011-08-31 13:55           ` Deniz Dogan
  2011-08-31 14:33             ` Thierry Volpiatto
@ 2011-08-31 15:40             ` Dani Moncayo
  2011-08-31 15:45               ` Deniz Dogan
  2011-08-31 16:11               ` Drew Adams
  1 sibling, 2 replies; 31+ messages in thread
From: Dani Moncayo @ 2011-08-31 15:40 UTC (permalink / raw)
  To: Deniz Dogan; +Cc: 9406

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





^ permalink raw reply	[flat|nested] 31+ messages in thread

* bug#9406: 24.0.50; Use M-p/M-n to navigate through the kill ring
  2011-08-31 15:40             ` Dani Moncayo
@ 2011-08-31 15:45               ` Deniz Dogan
  2011-08-31 16:11               ` Drew Adams
  1 sibling, 0 replies; 31+ messages in thread
From: Deniz Dogan @ 2011-08-31 15:45 UTC (permalink / raw)
  To: Dani Moncayo; +Cc: 9406

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.






^ permalink raw reply	[flat|nested] 31+ messages in thread

* bug#9406: 24.0.50; Use M-p/M-n to navigate through the kill ring
  2011-08-31 13:01         ` Stefan Monnier
  2011-08-31 13:55           ` Deniz Dogan
  2011-08-31 15:33           ` Dani Moncayo
@ 2011-08-31 15:47           ` David De La Harpe Golden
  2011-08-31 16:36             ` Juri Linkov
  2 siblings, 1 reply; 31+ messages in thread
From: David De La Harpe Golden @ 2011-08-31 15:47 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 9406

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).





^ permalink raw reply	[flat|nested] 31+ messages in thread

* bug#9406: 24.0.50; Use M-p/M-n to navigate through the kill ring
  2011-08-31 15:40             ` Dani Moncayo
  2011-08-31 15:45               ` Deniz Dogan
@ 2011-08-31 16:11               ` Drew Adams
  1 sibling, 0 replies; 31+ messages in thread
From: Drew Adams @ 2011-08-31 16:11 UTC (permalink / raw)
  To: 'Dani Moncayo', 'Deniz Dogan'; +Cc: 9406

> 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.






^ permalink raw reply	[flat|nested] 31+ messages in thread

* bug#9406: 24.0.50; Use M-p/M-n to navigate through the kill ring
  2011-08-31 15:47           ` David De La Harpe Golden
@ 2011-08-31 16:36             ` Juri Linkov
  2011-08-31 21:18               ` Dani Moncayo
  0 siblings, 1 reply; 31+ messages in thread
From: Juri Linkov @ 2011-08-31 16:36 UTC (permalink / raw)
  To: David De La Harpe Golden; +Cc: 9406

> 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.





^ permalink raw reply	[flat|nested] 31+ messages in thread

* bug#9406: 24.0.50; Use M-p/M-n to navigate through the kill ring
  2011-08-31 16:36             ` Juri Linkov
@ 2011-08-31 21:18               ` Dani Moncayo
  2011-09-01  8:42                 ` Juri Linkov
  0 siblings, 1 reply; 31+ messages in thread
From: Dani Moncayo @ 2011-08-31 21:18 UTC (permalink / raw)
  To: 9406

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





^ permalink raw reply	[flat|nested] 31+ messages in thread

* bug#9406: 24.0.50; Use M-p/M-n to navigate through the kill ring
  2011-08-31 21:18               ` Dani Moncayo
@ 2011-09-01  8:42                 ` Juri Linkov
  2011-09-01  9:13                   ` Dani Moncayo
  0 siblings, 1 reply; 31+ messages in thread
From: Juri Linkov @ 2011-09-01  8:42 UTC (permalink / raw)
  To: Dani Moncayo; +Cc: 9406

> 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').





^ permalink raw reply	[flat|nested] 31+ messages in thread

* bug#9406: 24.0.50; Use M-p/M-n to navigate through the kill ring
  2011-09-01  8:42                 ` Juri Linkov
@ 2011-09-01  9:13                   ` Dani Moncayo
  2011-09-01  9:53                     ` Antoine Levitt
  2011-09-01 13:22                     ` Juri Linkov
  0 siblings, 2 replies; 31+ messages in thread
From: Dani Moncayo @ 2011-09-01  9:13 UTC (permalink / raw)
  To: Juri Linkov; +Cc: 9406

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





^ permalink raw reply	[flat|nested] 31+ messages in thread

* bug#9406: 24.0.50; Use M-p/M-n to navigate through the kill ring
  2011-09-01  9:13                   ` Dani Moncayo
@ 2011-09-01  9:53                     ` Antoine Levitt
  2011-09-01 10:28                       ` Dani Moncayo
  2011-09-01 13:22                     ` Juri Linkov
  1 sibling, 1 reply; 31+ messages in thread
From: Antoine Levitt @ 2011-09-01  9:53 UTC (permalink / raw)
  To: 9406

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.






^ permalink raw reply	[flat|nested] 31+ messages in thread

* bug#9406: 24.0.50; Use M-p/M-n to navigate through the kill ring
  2011-09-01  9:53                     ` Antoine Levitt
@ 2011-09-01 10:28                       ` Dani Moncayo
  0 siblings, 0 replies; 31+ messages in thread
From: Dani Moncayo @ 2011-09-01 10:28 UTC (permalink / raw)
  To: 9406

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





^ permalink raw reply	[flat|nested] 31+ messages in thread

* bug#9406: 24.0.50; Use M-p/M-n to navigate through the kill ring
  2011-09-01  9:13                   ` Dani Moncayo
  2011-09-01  9:53                     ` Antoine Levitt
@ 2011-09-01 13:22                     ` Juri Linkov
  2011-09-01 14:44                       ` Dani Moncayo
  1 sibling, 1 reply; 31+ messages in thread
From: Juri Linkov @ 2011-09-01 13:22 UTC (permalink / raw)
  To: Dani Moncayo; +Cc: 9406

> 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.





^ permalink raw reply	[flat|nested] 31+ messages in thread

* bug#9406: 24.0.50; Use M-p/M-n to navigate through the kill ring
  2011-09-01 13:22                     ` Juri Linkov
@ 2011-09-01 14:44                       ` Dani Moncayo
  2011-09-01 19:59                         ` David De La Harpe Golden
  0 siblings, 1 reply; 31+ messages in thread
From: Dani Moncayo @ 2011-09-01 14:44 UTC (permalink / raw)
  To: Juri Linkov; +Cc: 9406

> 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





^ permalink raw reply	[flat|nested] 31+ messages in thread

* bug#9406: 24.0.50; Use M-p/M-n to navigate through the kill ring
  2011-09-01 14:44                       ` Dani Moncayo
@ 2011-09-01 19:59                         ` David De La Harpe Golden
  2011-09-01 21:56                           ` Dani Moncayo
  0 siblings, 1 reply; 31+ messages in thread
From: David De La Harpe Golden @ 2011-09-01 19:59 UTC (permalink / raw)
  To: Dani Moncayo; +Cc: 9406

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





^ permalink raw reply	[flat|nested] 31+ messages in thread

* bug#9406: 24.0.50; Use M-p/M-n to navigate through the kill ring
  2011-09-01 19:59                         ` David De La Harpe Golden
@ 2011-09-01 21:56                           ` Dani Moncayo
  2011-09-02  1:24                             ` David De La Harpe Golden
  0 siblings, 1 reply; 31+ messages in thread
From: Dani Moncayo @ 2011-09-01 21:56 UTC (permalink / raw)
  To: David De La Harpe Golden; +Cc: 9406

>> 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





^ permalink raw reply	[flat|nested] 31+ messages in thread

* bug#9406: 24.0.50; Use M-p/M-n to navigate through the kill ring
  2011-08-31 14:33             ` Thierry Volpiatto
  2011-08-31 14:52               ` Deniz Dogan
@ 2011-09-02  0:39               ` Stefan Monnier
  1 sibling, 0 replies; 31+ messages in thread
From: Stefan Monnier @ 2011-09-02  0:39 UTC (permalink / raw)
  To: 9406; +Cc: Thierry Volpiatto

>> 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))





^ permalink raw reply	[flat|nested] 31+ messages in thread

* bug#9406: 24.0.50; Use M-p/M-n to navigate through the kill ring
  2011-09-01 21:56                           ` Dani Moncayo
@ 2011-09-02  1:24                             ` David De La Harpe Golden
  0 siblings, 0 replies; 31+ messages in thread
From: David De La Harpe Golden @ 2011-09-02  1:24 UTC (permalink / raw)
  To: Dani Moncayo; +Cc: 9406

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)





^ permalink raw reply	[flat|nested] 31+ messages in thread

* bug#9406: 24.0.50; Use M-p/M-n to navigate through the kill ring
  2011-08-30 12:08 ` Juri Linkov
  2011-08-30 12:17   ` Dani Moncayo
@ 2022-04-27 14:21   ` Lars Ingebrigtsen
  1 sibling, 0 replies; 31+ messages in thread
From: Lars Ingebrigtsen @ 2022-04-27 14:21 UTC (permalink / raw)
  To: Juri Linkov; +Cc: Dani Moncayo, 9406

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





^ permalink raw reply	[flat|nested] 31+ messages in thread

end of thread, other threads:[~2022-04-27 14:21 UTC | newest]

Thread overview: 31+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-08-30 11:39 bug#9406: 24.0.50; Use M-p/M-n to navigate through the kill ring Dani Moncayo
2011-08-30 12:08 ` Juri Linkov
2011-08-30 12:17   ` Dani Moncayo
2011-08-30 12:27     ` Juri Linkov
2011-08-30 18:13       ` Deniz Dogan
2011-08-30 18:48         ` Dani Moncayo
2011-08-31  6:22       ` Dani Moncayo
2011-08-31  9:51         ` Juri Linkov
2011-08-31 10:45           ` Dani Moncayo
2011-08-31 13:01         ` Stefan Monnier
2011-08-31 13:55           ` Deniz Dogan
2011-08-31 14:33             ` Thierry Volpiatto
2011-08-31 14:52               ` Deniz Dogan
2011-09-02  0:39               ` Stefan Monnier
2011-08-31 15:40             ` Dani Moncayo
2011-08-31 15:45               ` Deniz Dogan
2011-08-31 16:11               ` Drew Adams
2011-08-31 15:33           ` Dani Moncayo
2011-08-31 15:47           ` David De La Harpe Golden
2011-08-31 16:36             ` Juri Linkov
2011-08-31 21:18               ` Dani Moncayo
2011-09-01  8:42                 ` Juri Linkov
2011-09-01  9:13                   ` Dani Moncayo
2011-09-01  9:53                     ` Antoine Levitt
2011-09-01 10:28                       ` Dani Moncayo
2011-09-01 13:22                     ` Juri Linkov
2011-09-01 14:44                       ` Dani Moncayo
2011-09-01 19:59                         ` David De La Harpe Golden
2011-09-01 21:56                           ` Dani Moncayo
2011-09-02  1:24                             ` David De La Harpe Golden
2022-04-27 14:21   ` Lars Ingebrigtsen

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.