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