* bug#48478: 28.0.50; yank-from-kill-ring and kill-ring-yank-pointer @ 2021-05-17 11:34 Eli Zaretskii 2021-05-17 14:35 ` Lars Ingebrigtsen 2021-05-17 21:10 ` Juri Linkov 0 siblings, 2 replies; 49+ messages in thread From: Eli Zaretskii @ 2021-05-17 11:34 UTC (permalink / raw) To: 48478; +Cc: Juri Linkov If one uses "C-y M-y M-y ... C-y", the last C-y will yank the same kill-ring entry that the M-y before it. But if one uses "M-y M-y ... C-y", the last C-y will yank not the entry produced by the last M-y, but the one after it. Which means yank-from-kill-ring leaves the kill-ring-yank-pointer at a different entry than yank-pop does. Bug or feature? If the latter, what is the rationale for the different operation? In GNU Emacs 28.0.50 (build 1311, i686-pc-mingw32) of 2021-05-17 built on HOME-C4E4A596F7 Repository revision: e761e12498ff108c3b82e9d27843baec6670447c Repository branch: master Windowing system distributor 'Microsoft Corp.', version 5.1.2600 System Description: Microsoft Windows XP Service Pack 3 (v5.1.0.2600) Configured using: 'configure -C --prefix=/d/usr --with-wide-int --with-modules --enable-checking=yes,glyphs 'CFLAGS=-O0 -gdwarf-4 -g3'' Configured features: ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 LIBXML2 MODULES NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND THREADS TIFF TOOLKIT_SCROLL_BARS XPM ZLIB Important settings: value of $LANG: ENU locale-coding-system: cp1255 Major mode: Lisp Interaction Minor modes in effect: tooltip-mode: t global-eldoc-mode: t eldoc-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t Load-path shadows: None found. Features: (shadow sort mail-extr dabbrev emacsbug message rmc puny dired dired-loaddefs rfc822 mml mml-sec epa derived epg epg-config gnus-util rmail rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs password-cache json map text-property-search time-date subr-x seq byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils iso-transl tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel dos-w32 ls-lisp disp-table term/w32-win w32-win w32-vars term/common-win tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite charscript charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button loaddefs faces cus-face macroexp files window text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote threads w32notify w32 lcms2 multi-tty make-network-process emacs) Memory information: ((conses 16 58121 11610) (symbols 48 7814 1) (strings 16 21681 2700) (string-bytes 1 636473) (vectors 16 13335) (vector-slots 8 171361 11466) (floats 8 27 47) (intervals 40 315 68) (buffers 888 11)) ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#48478: 28.0.50; yank-from-kill-ring and kill-ring-yank-pointer 2021-05-17 11:34 bug#48478: 28.0.50; yank-from-kill-ring and kill-ring-yank-pointer Eli Zaretskii @ 2021-05-17 14:35 ` Lars Ingebrigtsen 2021-05-17 21:10 ` Juri Linkov 1 sibling, 0 replies; 49+ messages in thread From: Lars Ingebrigtsen @ 2021-05-17 14:35 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 48478, Juri Linkov Eli Zaretskii <eliz@gnu.org> writes: > If one uses "C-y M-y M-y ... C-y", the last C-y will yank the > same kill-ring entry that the M-y before it. But if one uses > "M-y M-y ... C-y", the last C-y will yank not the entry produced > by the last M-y, but the one after it. Which means > yank-from-kill-ring leaves the kill-ring-yank-pointer at a different > entry than yank-pop does. > > Bug or feature? If the latter, what is the rationale for the > different operation? It feels like a bug to me -- I expect the `C-y' in both situations to produce the same text as the `M-y' before it. I think. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#48478: 28.0.50; yank-from-kill-ring and kill-ring-yank-pointer 2021-05-17 11:34 bug#48478: 28.0.50; yank-from-kill-ring and kill-ring-yank-pointer Eli Zaretskii 2021-05-17 14:35 ` Lars Ingebrigtsen @ 2021-05-17 21:10 ` Juri Linkov 2021-05-18 11:51 ` Eli Zaretskii 1 sibling, 1 reply; 49+ messages in thread From: Juri Linkov @ 2021-05-17 21:10 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 48478 [-- Attachment #1: Type: text/plain, Size: 1546 bytes --] > If one uses "C-y M-y M-y ... C-y", the last C-y will yank the > same kill-ring entry that the M-y before it. But if one uses > "M-y M-y ... C-y", the last C-y will yank not the entry produced > by the last M-y, but the one after it. Which means > yank-from-kill-ring leaves the kill-ring-yank-pointer at a different > entry than yank-pop does. > > Bug or feature? If the latter, what is the rationale for the > different operation? This is an unfinished feature, i.e. currently yank-from-kill-ring simply has no special handling of kill-ring-yank-pointer. When I tried to add it, I noticed that it has many possible variants of implementation, so I stuck with analysis paralysis. Perhaps we should have a new option with several choices: 1. Don't change kill-ring-yank-pointer (as it does now). This is useful when the user wants to type a predictable number of M-p in the minibuffer history to yank the same previously-killed text from the kill-ring several times. 2. Adjust kill-ring-yank-pointer to point to the selected text. 3. Still unclear how to adjust kill-ring-yank-pointer when the user selects a previous text then edits it before yanking. Regarding 7b82584c69, actually the description of 'M-y' in (info "(emacs) Isearch Yank") was accurate. It correctly described the behavior of isearch-yank-pop that activates the minibuffer. The problem is that after recent controversy, 'M-y' was rebound to the backward-compatible command isearch-yank-pop-only. A FIXME from 7b82584c69 is implemented by this patch: [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: read-from-kill-ring-prompt.patch --] [-- Type: text/x-diff, Size: 2348 bytes --] diff --git a/lisp/isearch.el b/lisp/isearch.el index 095f8ba145..c52718d94a 100644 --- a/lisp/isearch.el +++ b/lisp/isearch.el @@ -2583,7 +2585,7 @@ isearch-yank-from-kill-ring "Read a string from the `kill-ring' and append it to the search string." (interactive) (with-isearch-suspended - (let ((string (read-from-kill-ring))) + (let ((string (read-from-kill-ring "Yank from kill-ring: "))) (if (and isearch-case-fold-search (eq 'not-yanks search-upper-case)) (setq string (downcase string))) diff --git a/lisp/simple.el b/lisp/simple.el index 90942df0da..08c7c903a8 100644 --- a/lisp/simple.el +++ b/lisp/simple.el @@ -5587,7 +5587,8 @@ yank-pop property, in the way that `yank' does." (interactive "p") (if (not (eq last-command 'yank)) - (yank-from-kill-ring (read-from-kill-ring) current-prefix-arg) + (yank-from-kill-ring (read-from-kill-ring "Yank from kill-ring: ") + current-prefix-arg) (setq this-command 'yank) (unless arg (setq arg 1)) (let ((inhibit-read-only t) @@ -5676,7 +5677,7 @@ rotate-yank-pointer (current-kill arg)) (defvar read-from-kill-ring-history) -(defun read-from-kill-ring () +(defun read-from-kill-ring (prompt) "Read a `kill-ring' entry using completion and minibuffer history." ;; `current-kill' updates `kill-ring' with a possible interprogram-paste (current-kill 0) @@ -5721,11 +5722,7 @@ read-from-kill-ring (define-key map "?" nil) map))) (completing-read - ;; FIXME: This prompt is specific to using this function from - ;; yank-related commands, but the function could be used in - ;; other contexts. Should the prompt be passed via an - ;; argument? - "Yank from kill-ring: " + prompt (lambda (string pred action) (if (eq action 'metadata) ;; Keep sorted by recency @@ -5755,7 +5752,8 @@ yank-from-kill-ring beginning of the inserted text and mark at the end, like `yank' does. When called from Lisp, insert STRING like `insert-for-yank' does." - (interactive (list (read-from-kill-ring) current-prefix-arg)) + (interactive (list (read-from-kill-ring "Yank from kill-ring: ") + current-prefix-arg)) (push-mark) (insert-for-yank string) (if (consp arg) ^ permalink raw reply related [flat|nested] 49+ messages in thread
* bug#48478: 28.0.50; yank-from-kill-ring and kill-ring-yank-pointer 2021-05-17 21:10 ` Juri Linkov @ 2021-05-18 11:51 ` Eli Zaretskii 2021-05-18 20:24 ` Juri Linkov 0 siblings, 1 reply; 49+ messages in thread From: Eli Zaretskii @ 2021-05-18 11:51 UTC (permalink / raw) To: Juri Linkov; +Cc: 48478 > From: Juri Linkov <juri@linkov.net> > Cc: bug-gnu-emacs@gnu.org > Date: Tue, 18 May 2021 00:10:57 +0300 > > > Bug or feature? If the latter, what is the rationale for the > > different operation? > > This is an unfinished feature, i.e. currently yank-from-kill-ring > simply has no special handling of kill-ring-yank-pointer. > When I tried to add it, I noticed that it has many possible > variants of implementation, so I stuck with analysis paralysis. Why do we need variants? why not simply do the same as M-y does after C-y or M-y? After all, from the user's POV it's the same command, so why not provide a consistent behavior? > Regarding 7b82584c69, actually the description of 'M-y' in > (info "(emacs) Isearch Yank") was accurate. It correctly > described the behavior of isearch-yank-pop that activates > the minibuffer. The problem is that after recent controversy, > 'M-y' was rebound to the backward-compatible command > isearch-yank-pop-only. The last sentence means that the description in the manual which I deleted was indeed inaccurate: it described a binding that doesn't exist by default. NEWS does a better job by telling users to make that binding if they want. (I decided that saying the same in the manual was too much: we don't describe optional keybindings unless they are extremely useful/important.) > A FIXME from 7b82584c69 is implemented by this patch: Thanks, I think you should install this. > -(defun read-from-kill-ring () > +(defun read-from-kill-ring (prompt) > "Read a `kill-ring' entry using completion and minibuffer history." Please update the doc string to mention PROMPT. ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#48478: 28.0.50; yank-from-kill-ring and kill-ring-yank-pointer 2021-05-18 11:51 ` Eli Zaretskii @ 2021-05-18 20:24 ` Juri Linkov 2021-05-19 2:30 ` Eli Zaretskii 0 siblings, 1 reply; 49+ messages in thread From: Juri Linkov @ 2021-05-18 20:24 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 48478 >> This is an unfinished feature, i.e. currently yank-from-kill-ring >> simply has no special handling of kill-ring-yank-pointer. >> When I tried to add it, I noticed that it has many possible >> variants of implementation, so I stuck with analysis paralysis. > > Why do we need variants? why not simply do the same as M-y does after > C-y or M-y? After all, from the user's POV it's the same command, so > why not provide a consistent behavior? No one objected until now, so there are users who prefer the current behavior. But I don't disagree with changing the default to use kill-ring-yank-pointer. >> A FIXME from 7b82584c69 is implemented by this patch: > > Thanks, I think you should install this. Installed. >> -(defun read-from-kill-ring () >> +(defun read-from-kill-ring (prompt) >> "Read a `kill-ring' entry using completion and minibuffer history." > > Please update the doc string to mention PROMPT. Done. ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#48478: 28.0.50; yank-from-kill-ring and kill-ring-yank-pointer 2021-05-18 20:24 ` Juri Linkov @ 2021-05-19 2:30 ` Eli Zaretskii 2021-05-19 16:31 ` Juri Linkov 0 siblings, 1 reply; 49+ messages in thread From: Eli Zaretskii @ 2021-05-19 2:30 UTC (permalink / raw) To: Juri Linkov; +Cc: 48478 > From: Juri Linkov <juri@linkov.net> > Cc: 48478@debbugs.gnu.org > Date: Tue, 18 May 2021 23:24:24 +0300 > > >> This is an unfinished feature, i.e. currently yank-from-kill-ring > >> simply has no special handling of kill-ring-yank-pointer. > >> When I tried to add it, I noticed that it has many possible > >> variants of implementation, so I stuck with analysis paralysis. > > > > Why do we need variants? why not simply do the same as M-y does after > > C-y or M-y? After all, from the user's POV it's the same command, so > > why not provide a consistent behavior? > > No one objected until now, so there are users who prefer the current behavior. Well, I objected the first time I used this feature after learning about it. The reason is that what M-y does after C-y is described in the manual, so I wanted to see what this new feature does, and was puzzled by what it did. > But I don't disagree with changing the default to use kill-ring-yank-pointer. Let's please do that, TIA. ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#48478: 28.0.50; yank-from-kill-ring and kill-ring-yank-pointer 2021-05-19 2:30 ` Eli Zaretskii @ 2021-05-19 16:31 ` Juri Linkov 2021-05-20 9:32 ` Eli Zaretskii 0 siblings, 1 reply; 49+ messages in thread From: Juri Linkov @ 2021-05-19 16:31 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 48478 >> But I don't disagree with changing the default to use kill-ring-yank-pointer. > > Let's please do that, TIA. Now pushed in commit 1f0f922ef2, please close if everything is ok. ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#48478: 28.0.50; yank-from-kill-ring and kill-ring-yank-pointer 2021-05-19 16:31 ` Juri Linkov @ 2021-05-20 9:32 ` Eli Zaretskii 2021-05-20 18:02 ` Juri Linkov 0 siblings, 1 reply; 49+ messages in thread From: Eli Zaretskii @ 2021-05-20 9:32 UTC (permalink / raw) To: Juri Linkov; +Cc: 48478 > From: Juri Linkov <juri@linkov.net> > Cc: 48478@debbugs.gnu.org > Date: Wed, 19 May 2021 19:31:06 +0300 > > >> But I don't disagree with changing the default to use kill-ring-yank-pointer. > > > > Let's please do that, TIA. > > Now pushed in commit 1f0f922ef2, please close if everything is ok. Thanks, but it doesn't seem to work like I expected. Here's what I did: . emacs -Q . Mark several words of the comment in *scratch*, one by one, and type M-w to copy each one of them to the kill-ring . M-y, then type the beginning of one of the saved words (not the last one), type TAB to complete, then type RET to insert . C-y The last didn't C-y insert the word inserted before it by M-y, it inserted the word in the previous slot of kill-ring. ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#48478: 28.0.50; yank-from-kill-ring and kill-ring-yank-pointer 2021-05-20 9:32 ` Eli Zaretskii @ 2021-05-20 18:02 ` Juri Linkov 2021-05-20 19:04 ` Eli Zaretskii 0 siblings, 1 reply; 49+ messages in thread From: Juri Linkov @ 2021-05-20 18:02 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 48478 >> Now pushed in commit 1f0f922ef2, please close if everything is ok. > > Thanks, but it doesn't seem to work like I expected. > > Here's what I did: > > . emacs -Q > . Mark several words of the comment in *scratch*, one by one, and > type M-w to copy each one of them to the kill-ring > . M-y, then type the beginning of one of the saved words (not the > last one), type TAB to complete, then type RET to insert > . C-y > > The last didn't C-y insert the word inserted before it by M-y, it > inserted the word in the previous slot of kill-ring. I didn't expect this case should be handled as well. Now this is fixed in commit ef7a6eec20. ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#48478: 28.0.50; yank-from-kill-ring and kill-ring-yank-pointer 2021-05-20 18:02 ` Juri Linkov @ 2021-05-20 19:04 ` Eli Zaretskii 2021-05-20 19:56 ` Juri Linkov 0 siblings, 1 reply; 49+ messages in thread From: Eli Zaretskii @ 2021-05-20 19:04 UTC (permalink / raw) To: Juri Linkov; +Cc: 48478 > From: Juri Linkov <juri@linkov.net> > Cc: 48478@debbugs.gnu.org > Date: Thu, 20 May 2021 21:02:56 +0300 > > > The last didn't C-y insert the word inserted before it by M-y, it > > inserted the word in the previous slot of kill-ring. > > I didn't expect this case should be handled as well. > Now this is fixed in commit ef7a6eec20. Thanks, this use case now works. However, I'm not sure I understand what happens when I edit the kill-ring entry before hitting RET, which gets it inserted. Is the edited entry added to the kill-ring? It looks like it isn't, because the next C-y inserts the last kill-ring entry, i.e. neither the original entry I edited nor the edited entry actually inserted. Why does the kill-ring-yank-pointer gets reset to the front of the kill-ring in this case? ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#48478: 28.0.50; yank-from-kill-ring and kill-ring-yank-pointer 2021-05-20 19:04 ` Eli Zaretskii @ 2021-05-20 19:56 ` Juri Linkov 2021-05-20 20:10 ` Eli Zaretskii 2021-05-30 22:23 ` Juri Linkov 0 siblings, 2 replies; 49+ messages in thread From: Juri Linkov @ 2021-05-20 19:56 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 48478 > However, I'm not sure I understand what happens when I edit the > kill-ring entry before hitting RET, which gets it inserted. Is the > edited entry added to the kill-ring? It looks like it isn't, because > the next C-y inserts the last kill-ring entry, i.e. neither the > original entry I edited nor the edited entry actually inserted. Why > does the kill-ring-yank-pointer gets reset to the front of the > kill-ring in this case? After inserting the edited entry it resets the kill-ring-yank-pointer for the same reason why the kill-ring-yank-pointer gets reset when a new entry gets added to the kill-ring after C-w, i.e. like this line in 'kill-new': (setq kill-ring-yank-pointer kill-ring) ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#48478: 28.0.50; yank-from-kill-ring and kill-ring-yank-pointer 2021-05-20 19:56 ` Juri Linkov @ 2021-05-20 20:10 ` Eli Zaretskii 2021-05-20 20:44 ` Juri Linkov 2021-05-30 22:23 ` Juri Linkov 1 sibling, 1 reply; 49+ messages in thread From: Eli Zaretskii @ 2021-05-20 20:10 UTC (permalink / raw) To: Juri Linkov; +Cc: 48478 > From: Juri Linkov <juri@linkov.net> > Cc: 48478@debbugs.gnu.org > Date: Thu, 20 May 2021 22:56:35 +0300 > > > However, I'm not sure I understand what happens when I edit the > > kill-ring entry before hitting RET, which gets it inserted. Is the > > edited entry added to the kill-ring? It looks like it isn't, because > > the next C-y inserts the last kill-ring entry, i.e. neither the > > original entry I edited nor the edited entry actually inserted. Why > > does the kill-ring-yank-pointer gets reset to the front of the > > kill-ring in this case? > > After inserting the edited entry it resets the kill-ring-yank-pointer > for the same reason why the kill-ring-yank-pointer gets reset > when a new entry gets added to the kill-ring after C-w, > i.e. like this line in 'kill-new': > > (setq kill-ring-yank-pointer kill-ring) I could understand that if the edited entry were added to the kill-ring. But it isn't is it? ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#48478: 28.0.50; yank-from-kill-ring and kill-ring-yank-pointer 2021-05-20 20:10 ` Eli Zaretskii @ 2021-05-20 20:44 ` Juri Linkov 2021-05-21 5:51 ` Eli Zaretskii 0 siblings, 1 reply; 49+ messages in thread From: Juri Linkov @ 2021-05-20 20:44 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 48478 >> > However, I'm not sure I understand what happens when I edit the >> > kill-ring entry before hitting RET, which gets it inserted. Is the >> > edited entry added to the kill-ring? It looks like it isn't, because >> > the next C-y inserts the last kill-ring entry, i.e. neither the >> > original entry I edited nor the edited entry actually inserted. Why >> > does the kill-ring-yank-pointer gets reset to the front of the >> > kill-ring in this case? >> >> After inserting the edited entry it resets the kill-ring-yank-pointer >> for the same reason why the kill-ring-yank-pointer gets reset >> when a new entry gets added to the kill-ring after C-w, >> i.e. like this line in 'kill-new': >> >> (setq kill-ring-yank-pointer kill-ring) > > I could understand that if the edited entry were added to the > kill-ring. But it isn't is it? It would be unexpected when yanking the edited entry with M-y would add it to the kill-ring as its opposite command M-w does. ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#48478: 28.0.50; yank-from-kill-ring and kill-ring-yank-pointer 2021-05-20 20:44 ` Juri Linkov @ 2021-05-21 5:51 ` Eli Zaretskii 2021-05-21 18:18 ` Juri Linkov 0 siblings, 1 reply; 49+ messages in thread From: Eli Zaretskii @ 2021-05-21 5:51 UTC (permalink / raw) To: Juri Linkov; +Cc: 48478 > From: Juri Linkov <juri@linkov.net> > Cc: 48478@debbugs.gnu.org > Date: Thu, 20 May 2021 23:44:22 +0300 > > >> > However, I'm not sure I understand what happens when I edit the > >> > kill-ring entry before hitting RET, which gets it inserted. Is the > >> > edited entry added to the kill-ring? It looks like it isn't, because > >> > the next C-y inserts the last kill-ring entry, i.e. neither the > >> > original entry I edited nor the edited entry actually inserted. Why > >> > does the kill-ring-yank-pointer gets reset to the front of the > >> > kill-ring in this case? > >> > >> After inserting the edited entry it resets the kill-ring-yank-pointer > >> for the same reason why the kill-ring-yank-pointer gets reset > >> when a new entry gets added to the kill-ring after C-w, > >> i.e. like this line in 'kill-new': > >> > >> (setq kill-ring-yank-pointer kill-ring) > > > > I could understand that if the edited entry were added to the > > kill-ring. But it isn't is it? > > It would be unexpected when yanking the edited entry with M-y > would add it to the kill-ring as its opposite command M-w does. Why unexpected? If we document that, it wouldn't be unexpected. Once again, we could decide to either add the edited entry to kill-ring or not add it. If we don't add it, kill-ring-yank-pointer should stay at its position, which corresponds to the original entry before the editing. If we do add it, the pointer should be reset to the slot where the edited entry is. Both of these behaviors can be easily documented and will be reasonably logical and intuitive, because they are basically similar to what the old M-y did. What we do now is much harder to explain and is not intuitive, at least not according to my intuition. Does anyone else have an opinion about this? ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#48478: 28.0.50; yank-from-kill-ring and kill-ring-yank-pointer 2021-05-21 5:51 ` Eli Zaretskii @ 2021-05-21 18:18 ` Juri Linkov 2021-05-22 6:41 ` Eli Zaretskii 0 siblings, 1 reply; 49+ messages in thread From: Juri Linkov @ 2021-05-21 18:18 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 48478 >> It would be unexpected when yanking the edited entry with M-y >> would add it to the kill-ring as its opposite command M-w does. > > Why unexpected? If we document that, it wouldn't be unexpected. > > Once again, we could decide to either add the edited entry to > kill-ring or not add it. If we don't add it, kill-ring-yank-pointer > should stay at its position, which corresponds to the original entry > before the editing. If we do add it, the pointer should be reset to > the slot where the edited entry is. Both of these behaviors can be > easily documented and will be reasonably logical and intuitive, > because they are basically similar to what the old M-y did. What we > do now is much harder to explain and is not intuitive, at least not > according to my intuition. For the case of not adding the edited entry to the kill-ring, now kill-ring-yank-pointer stays at the same position it was before the editing. > Does anyone else have an opinion about this? Regarding the question whether to add the edited entry to the kill-ring, let's hear more opinions. ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#48478: 28.0.50; yank-from-kill-ring and kill-ring-yank-pointer 2021-05-21 18:18 ` Juri Linkov @ 2021-05-22 6:41 ` Eli Zaretskii 2021-05-22 20:59 ` Juri Linkov 0 siblings, 1 reply; 49+ messages in thread From: Eli Zaretskii @ 2021-05-22 6:41 UTC (permalink / raw) To: Juri Linkov; +Cc: 48478 > From: Juri Linkov <juri@linkov.net> > Cc: 48478@debbugs.gnu.org > Date: Fri, 21 May 2021 21:18:33 +0300 > > >> It would be unexpected when yanking the edited entry with M-y > >> would add it to the kill-ring as its opposite command M-w does. > > > > Why unexpected? If we document that, it wouldn't be unexpected. > > > > Once again, we could decide to either add the edited entry to > > kill-ring or not add it. If we don't add it, kill-ring-yank-pointer > > should stay at its position, which corresponds to the original entry > > before the editing. If we do add it, the pointer should be reset to > > the slot where the edited entry is. Both of these behaviors can be > > easily documented and will be reasonably logical and intuitive, > > because they are basically similar to what the old M-y did. What we > > do now is much harder to explain and is not intuitive, at least not > > according to my intuition. > > For the case of not adding the edited entry to the kill-ring, > now kill-ring-yank-pointer stays at the same position it was > before the editing. It doesn't look like that in my testing. Here's the recipe: emacs -Q For the words "buffer", "text", "Lisp", and "evaluation" from the first line, mark each word and then M-w M-> M-y Type "tex TAB", which will expand to "text" Type "oize RET", which will insert "textoize" Type C-y This inserts the last kill, which is "evaluation", whereas I expected to see "text", since you said the pointer stays at the same position. What am I missing here? > > Does anyone else have an opinion about this? > > Regarding the question whether to add the edited entry to the kill-ring, > let's hear more opinions. OK. ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#48478: 28.0.50; yank-from-kill-ring and kill-ring-yank-pointer 2021-05-22 6:41 ` Eli Zaretskii @ 2021-05-22 20:59 ` Juri Linkov 2021-05-23 7:19 ` Eli Zaretskii 0 siblings, 1 reply; 49+ messages in thread From: Juri Linkov @ 2021-05-22 20:59 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 48478 >> For the case of not adding the edited entry to the kill-ring, >> now kill-ring-yank-pointer stays at the same position it was >> before the editing. > > It doesn't look like that in my testing. Here's the recipe: > > emacs -Q > For the words "buffer", "text", "Lisp", and "evaluation" from the > first line, mark each word and then M-w > M-> > M-y > Type "tex TAB", which will expand to "text" > Type "oize RET", which will insert "textoize" > Type C-y > This inserts the last kill, which is "evaluation", whereas I > expected to see "text", since you said the pointer stays at the > same position. The pointer kill-ring-yank-pointer stays at the same position: before M-y, kill-ring-yank-pointer points to "evaluation", and after M-y, kill-ring-yank-pointer points to "evaluation". ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#48478: 28.0.50; yank-from-kill-ring and kill-ring-yank-pointer 2021-05-22 20:59 ` Juri Linkov @ 2021-05-23 7:19 ` Eli Zaretskii 2021-05-25 20:35 ` Juri Linkov 0 siblings, 1 reply; 49+ messages in thread From: Eli Zaretskii @ 2021-05-23 7:19 UTC (permalink / raw) To: Juri Linkov; +Cc: 48478 > From: Juri Linkov <juri@linkov.net> > Cc: 48478@debbugs.gnu.org > Date: Sat, 22 May 2021 23:59:31 +0300 > > >> For the case of not adding the edited entry to the kill-ring, > >> now kill-ring-yank-pointer stays at the same position it was > >> before the editing. > > > > It doesn't look like that in my testing. Here's the recipe: > > > > emacs -Q > > For the words "buffer", "text", "Lisp", and "evaluation" from the > > first line, mark each word and then M-w > > M-> > > M-y > > Type "tex TAB", which will expand to "text" > > Type "oize RET", which will insert "textoize" > > Type C-y > > This inserts the last kill, which is "evaluation", whereas I > > expected to see "text", since you said the pointer stays at the > > same position. > > The pointer kill-ring-yank-pointer stays at the same position: > before M-y, kill-ring-yank-pointer points to "evaluation", > and after M-y, kill-ring-yank-pointer points to "evaluation". I think this is not the optimal behavior. The optimal behavior IMO is if M-y would yield the same results wrt kill-ring-yank-pointer as does M-y after C-y. IOW, it would be natural if M-y invoked after a non-yank command would just allow a "direct access" to a specific slot of the kill-ring, and would otherwise work like M-y after a yank command. Once again, from user's POV M-y is the same command, so every subtle change in the results is IMO a disadvantage, if the change is not a direct consequence of the differences in use cases. If you want yank-from-kill-ring to leave kill-ring-yank-pointer unaltered, we could move the pointer in yank-pop, after yank-from-kill-ring returns. WDYT? ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#48478: 28.0.50; yank-from-kill-ring and kill-ring-yank-pointer 2021-05-23 7:19 ` Eli Zaretskii @ 2021-05-25 20:35 ` Juri Linkov 2021-05-26 12:05 ` Eli Zaretskii 0 siblings, 1 reply; 49+ messages in thread From: Juri Linkov @ 2021-05-25 20:35 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 48478 >> The pointer kill-ring-yank-pointer stays at the same position: >> before M-y, kill-ring-yank-pointer points to "evaluation", >> and after M-y, kill-ring-yank-pointer points to "evaluation". > > I think this is not the optimal behavior. The optimal behavior IMO is > if M-y would yield the same results wrt kill-ring-yank-pointer as does > M-y after C-y. IOW, it would be natural if M-y invoked after a > non-yank command would just allow a "direct access" to a specific slot > of the kill-ring, and would otherwise work like M-y after a yank > command. Once again, from user's POV M-y is the same command, so > every subtle change in the results is IMO a disadvantage, if the > change is not a direct consequence of the differences in use cases. > > If you want yank-from-kill-ring to leave kill-ring-yank-pointer > unaltered, we could move the pointer in yank-pop, after > yank-from-kill-ring returns. WDYT? When yank-from-kill-ring returns an edited string, how yank-pop could use it to adjust kill-ring-yank-pointer? ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#48478: 28.0.50; yank-from-kill-ring and kill-ring-yank-pointer 2021-05-25 20:35 ` Juri Linkov @ 2021-05-26 12:05 ` Eli Zaretskii 2021-05-26 22:09 ` Juri Linkov 0 siblings, 1 reply; 49+ messages in thread From: Eli Zaretskii @ 2021-05-26 12:05 UTC (permalink / raw) To: Juri Linkov; +Cc: 48478 > From: Juri Linkov <juri@linkov.net> > Cc: 48478@debbugs.gnu.org > Date: Tue, 25 May 2021 23:35:48 +0300 > > > If you want yank-from-kill-ring to leave kill-ring-yank-pointer > > unaltered, we could move the pointer in yank-pop, after > > yank-from-kill-ring returns. WDYT? > > When yank-from-kill-ring returns an edited string, When does it do that? AFAICT, it _inserts_ the edited string. > how yank-pop could use it to adjust kill-ring-yank-pointer? yank-from-kill-ring is a new function, and its return value isn't documented. So you could change it to return kill-ring-yank-pointer instead, and then yank-pop could move it. ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#48478: 28.0.50; yank-from-kill-ring and kill-ring-yank-pointer 2021-05-26 12:05 ` Eli Zaretskii @ 2021-05-26 22:09 ` Juri Linkov 2021-05-27 7:30 ` Eli Zaretskii 0 siblings, 1 reply; 49+ messages in thread From: Juri Linkov @ 2021-05-26 22:09 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 48478 >> > If you want yank-from-kill-ring to leave kill-ring-yank-pointer >> > unaltered, we could move the pointer in yank-pop, after >> > yank-from-kill-ring returns. WDYT? >> >> When yank-from-kill-ring returns an edited string, > > When does it do that? AFAICT, it _inserts_ the edited string. Sorry, I meant this: When read-from-kill-ring returns an edited string, how yank-from-kill-ring could use it to adjust kill-ring-yank-pointer? > yank-from-kill-ring is a new function, and its return value isn't > documented. So you could change it to return kill-ring-yank-pointer > instead, and then yank-pop could move it. I don't understand what value of kill-ring-yank-pointer should be returned: its old value or some modified value? BTW, the recent fix in ef7a6eec20 broke such use case: M-w on some region, but then M-y M-p doesn't insert the last item to the minibuffer, i.e. the same item that is inserted to the buffer by C-y. Here is a workaround: diff --git a/lisp/simple.el b/lisp/simple.el index 0d4a712b39..7014f1c24c 100644 --- a/lisp/simple.el +++ b/lisp/simple.el @@ -5735,7 +5736,8 @@ read-from-kill-ring (complete-with-action action completions string pred))) nil nil nil (if history-pos - (cons 'read-from-kill-ring-history (1+ history-pos)) + (cons 'read-from-kill-ring-history + (if (zerop history-pos) history-pos (1+ history-pos))) 'read-from-kill-ring-history))))) ^ permalink raw reply related [flat|nested] 49+ messages in thread
* bug#48478: 28.0.50; yank-from-kill-ring and kill-ring-yank-pointer 2021-05-26 22:09 ` Juri Linkov @ 2021-05-27 7:30 ` Eli Zaretskii 2021-05-30 22:32 ` Juri Linkov 0 siblings, 1 reply; 49+ messages in thread From: Eli Zaretskii @ 2021-05-27 7:30 UTC (permalink / raw) To: Juri Linkov; +Cc: 48478 > From: Juri Linkov <juri@linkov.net> > Cc: 48478@debbugs.gnu.org > Date: Thu, 27 May 2021 01:09:33 +0300 > > When read-from-kill-ring returns an edited string, > how yank-from-kill-ring could use it to adjust kill-ring-yank-pointer? read-from-kill-ring could store the pointer in some variable, I guess? > > yank-from-kill-ring is a new function, and its return value isn't > > documented. So you could change it to return kill-ring-yank-pointer > > instead, and then yank-pop could move it. > > I don't understand what value of kill-ring-yank-pointer > should be returned: its old value or some modified value? It depends on whether we add the edited string to the kill ring or not. Currently, we don't add it, so I think the value should be that of the unedited entry in the kill ring. > BTW, the recent fix in ef7a6eec20 broke such use case: > M-w on some region, but then M-y M-p doesn't insert the last item > to the minibuffer, i.e. the same item that is inserted to the buffer Sorry, I don't understand how does minibiffer enter the picture. Can you show a complete recipe? ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#48478: 28.0.50; yank-from-kill-ring and kill-ring-yank-pointer 2021-05-27 7:30 ` Eli Zaretskii @ 2021-05-30 22:32 ` Juri Linkov 2021-05-31 12:08 ` Eli Zaretskii 0 siblings, 1 reply; 49+ messages in thread From: Juri Linkov @ 2021-05-30 22:32 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 48478 >> When read-from-kill-ring returns an edited string, >> how yank-from-kill-ring could use it to adjust kill-ring-yank-pointer? > > read-from-kill-ring could store the pointer in some variable, I guess? There is no way to get the pointer to point to the entry of the kill ring, because we can't find the edited string in the kill ring. >> > yank-from-kill-ring is a new function, and its return value isn't >> > documented. So you could change it to return kill-ring-yank-pointer >> > instead, and then yank-pop could move it. >> >> I don't understand what value of kill-ring-yank-pointer >> should be returned: its old value or some modified value? > > It depends on whether we add the edited string to the kill ring or > not. Currently, we don't add it, so I think the value should be that > of the unedited entry in the kill ring. The minibuffer returns only the edited entry that we can't use to find the unedited entry in the kill ring. >> BTW, the recent fix in ef7a6eec20 broke such use case: >> M-w on some region, but then M-y M-p doesn't insert the last item >> to the minibuffer, i.e. the same item that is inserted to the buffer > > Sorry, I don't understand how does minibiffer enter the picture. Can > you show a complete recipe? M-y activates the minibuffer and uses its (HISTVAR . HISTPOS) to set the initial position for use by the minibuffer history to the entry pointed by kill-ring-yank-pointer. So this is similar to what C-y does when it yanks the same entry pointed by kill-ring-yank-pointer. ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#48478: 28.0.50; yank-from-kill-ring and kill-ring-yank-pointer 2021-05-30 22:32 ` Juri Linkov @ 2021-05-31 12:08 ` Eli Zaretskii 2021-05-31 20:20 ` Juri Linkov 0 siblings, 1 reply; 49+ messages in thread From: Eli Zaretskii @ 2021-05-31 12:08 UTC (permalink / raw) To: Juri Linkov; +Cc: 48478 > From: Juri Linkov <juri@linkov.net> > Cc: 48478@debbugs.gnu.org > Date: Mon, 31 May 2021 01:32:15 +0300 > > >> When read-from-kill-ring returns an edited string, > >> how yank-from-kill-ring could use it to adjust kill-ring-yank-pointer? > > > > read-from-kill-ring could store the pointer in some variable, I guess? > > There is no way to get the pointer to point to the entry of the kill ring, > because we can't find the edited string in the kill ring. Then maybe this is another reason to prefer adding the edited string to the kill-ring? In which case you will need to reset the pointer to the head of the ring? > >> BTW, the recent fix in ef7a6eec20 broke such use case: > >> M-w on some region, but then M-y M-p doesn't insert the last item > >> to the minibuffer, i.e. the same item that is inserted to the buffer > > > > Sorry, I don't understand how does minibiffer enter the picture. Can > > you show a complete recipe? > > M-y activates the minibuffer and uses its (HISTVAR . HISTPOS) > to set the initial position for use by the minibuffer history > to the entry pointed by kill-ring-yank-pointer. So this is similar > to what C-y does when it yanks the same entry pointed by kill-ring-yank-pointer. If this is the scenario, then I don't see a problem: what you describe works for me, i.e. "M-y M-p" does insert the last killed item into the minibuffer. I wonder why it doesn't work for you. ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#48478: 28.0.50; yank-from-kill-ring and kill-ring-yank-pointer 2021-05-31 12:08 ` Eli Zaretskii @ 2021-05-31 20:20 ` Juri Linkov 2021-06-01 12:13 ` Eli Zaretskii 0 siblings, 1 reply; 49+ messages in thread From: Juri Linkov @ 2021-05-31 20:20 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 48478 >> >> When read-from-kill-ring returns an edited string, >> >> how yank-from-kill-ring could use it to adjust kill-ring-yank-pointer? >> > >> > read-from-kill-ring could store the pointer in some variable, I guess? >> >> There is no way to get the pointer to point to the entry of the kill ring, >> because we can't find the edited string in the kill ring. > > Then maybe this is another reason to prefer adding the edited string > to the kill-ring? In which case you will need to reset the pointer to > the head of the ring? When there is a need to add the edited string to the kill-ring, then better to do this explicitly by marking the whole contents of the edited minibuffer with 'C-x h', then adding it to the kill-ring with 'M-w'. >> >> BTW, the recent fix in ef7a6eec20 broke such use case: >> >> M-w on some region, but then M-y M-p doesn't insert the last item >> >> to the minibuffer, i.e. the same item that is inserted to the buffer >> > >> > Sorry, I don't understand how does minibiffer enter the picture. Can >> > you show a complete recipe? >> >> M-y activates the minibuffer and uses its (HISTVAR . HISTPOS) >> to set the initial position for use by the minibuffer history >> to the entry pointed by kill-ring-yank-pointer. So this is similar >> to what C-y does when it yanks the same entry pointed by kill-ring-yank-pointer. > > If this is the scenario, then I don't see a problem: what you describe > works for me, i.e. "M-y M-p" does insert the last killed item into the > minibuffer. I wonder why it doesn't work for you. I tried in 'emacs -Q', and 'M-y M-p' doesn't insert the last killed item into the minibuffer. ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#48478: 28.0.50; yank-from-kill-ring and kill-ring-yank-pointer 2021-05-31 20:20 ` Juri Linkov @ 2021-06-01 12:13 ` Eli Zaretskii 2021-06-01 20:32 ` Juri Linkov 0 siblings, 1 reply; 49+ messages in thread From: Eli Zaretskii @ 2021-06-01 12:13 UTC (permalink / raw) To: Juri Linkov; +Cc: 48478 > From: Juri Linkov <juri@linkov.net> > Cc: 48478@debbugs.gnu.org > Date: Mon, 31 May 2021 23:20:04 +0300 > > >> >> When read-from-kill-ring returns an edited string, > >> >> how yank-from-kill-ring could use it to adjust kill-ring-yank-pointer? > >> > > >> > read-from-kill-ring could store the pointer in some variable, I guess? > >> > >> There is no way to get the pointer to point to the entry of the kill ring, > >> because we can't find the edited string in the kill ring. > > > > Then maybe this is another reason to prefer adding the edited string > > to the kill-ring? In which case you will need to reset the pointer to > > the head of the ring? > > When there is a need to add the edited string to the kill-ring, > then better to do this explicitly by marking the whole contents of > the edited minibuffer with 'C-x h', then adding it to the kill-ring > with 'M-w'. Sure, but that's unrelated to the issue at hand, isn't it? > >> >> BTW, the recent fix in ef7a6eec20 broke such use case: > >> >> M-w on some region, but then M-y M-p doesn't insert the last item > >> >> to the minibuffer, i.e. the same item that is inserted to the buffer > >> > > >> > Sorry, I don't understand how does minibiffer enter the picture. Can > >> > you show a complete recipe? > >> > >> M-y activates the minibuffer and uses its (HISTVAR . HISTPOS) > >> to set the initial position for use by the minibuffer history > >> to the entry pointed by kill-ring-yank-pointer. So this is similar > >> to what C-y does when it yanks the same entry pointed by kill-ring-yank-pointer. > > > > If this is the scenario, then I don't see a problem: what you describe > > works for me, i.e. "M-y M-p" does insert the last killed item into the > > minibuffer. I wonder why it doesn't work for you. > > I tried in 'emacs -Q', and 'M-y M-p' doesn't insert the last killed item > into the minibuffer. It does here, so I guess we are doing something differently. Can you show a complete recipe, starting from "emacs -Q"? ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#48478: 28.0.50; yank-from-kill-ring and kill-ring-yank-pointer 2021-06-01 12:13 ` Eli Zaretskii @ 2021-06-01 20:32 ` Juri Linkov 2021-06-02 14:57 ` Eli Zaretskii 0 siblings, 1 reply; 49+ messages in thread From: Juri Linkov @ 2021-06-01 20:32 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 48478 >> I tried in 'emacs -Q', and 'M-y M-p' doesn't insert the last killed item >> into the minibuffer. > > It does here, so I guess we are doing something differently. Can you > show a complete recipe, starting from "emacs -Q"? 0. emacs -Q 1. select the word "This" and type M-w 2. select the word "buffer" and type M-w 3. type M-y M-p The minibuffer looks like: Yank from kill-ring: This but should be Yank from kill-ring: buffer ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#48478: 28.0.50; yank-from-kill-ring and kill-ring-yank-pointer 2021-06-01 20:32 ` Juri Linkov @ 2021-06-02 14:57 ` Eli Zaretskii 2021-06-02 21:10 ` Juri Linkov 0 siblings, 1 reply; 49+ messages in thread From: Eli Zaretskii @ 2021-06-02 14:57 UTC (permalink / raw) To: Juri Linkov; +Cc: 48478 > From: Juri Linkov <juri@linkov.net> > Cc: 48478@debbugs.gnu.org > Date: Tue, 01 Jun 2021 23:32:54 +0300 > > >> I tried in 'emacs -Q', and 'M-y M-p' doesn't insert the last killed item > >> into the minibuffer. > > > > It does here, so I guess we are doing something differently. Can you > > show a complete recipe, starting from "emacs -Q"? > > 0. emacs -Q > 1. select the word "This" and type M-w > 2. select the word "buffer" and type M-w > 3. type M-y M-p > > The minibuffer looks like: > > Yank from kill-ring: This > > but should be > > Yank from kill-ring: buffer So you don't like that M-p yields "This" and M-n yield "buffer" in this case? Why not? IOW, why did you expect M-p to yield "buffer"? This is M-y, not C-y. ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#48478: 28.0.50; yank-from-kill-ring and kill-ring-yank-pointer 2021-06-02 14:57 ` Eli Zaretskii @ 2021-06-02 21:10 ` Juri Linkov 2021-06-03 6:19 ` Eli Zaretskii 0 siblings, 1 reply; 49+ messages in thread From: Juri Linkov @ 2021-06-02 21:10 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 48478 >> 1. select the word "This" and type M-w >> 2. select the word "buffer" and type M-w >> 3. type M-y M-p >> >> The minibuffer looks like: >> >> Yank from kill-ring: This >> >> but should be >> >> Yank from kill-ring: buffer > > So you don't like that M-p yields "This" and M-n yield "buffer" in > this case? Why not? IOW, why did you expect M-p to yield "buffer"? > This is M-y, not C-y. But this is not 'M-y C-y'. The logic is the following: one key (either non-minibuffer 'C-y' or minibuffer 'M-y') should yank the last item, two keys (non-minibuffer 'C-y M-y') should yank the second last item. Another reason is that 'M-y M-p' can omit the last item only after a previous invocation of 'M-y' that rotated the pointer. ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#48478: 28.0.50; yank-from-kill-ring and kill-ring-yank-pointer 2021-06-02 21:10 ` Juri Linkov @ 2021-06-03 6:19 ` Eli Zaretskii 2021-06-03 20:55 ` Juri Linkov 0 siblings, 1 reply; 49+ messages in thread From: Eli Zaretskii @ 2021-06-03 6:19 UTC (permalink / raw) To: Juri Linkov; +Cc: 48478 > From: Juri Linkov <juri@linkov.net> > Cc: 48478@debbugs.gnu.org > Date: Thu, 03 Jun 2021 00:10:18 +0300 > > >> 1. select the word "This" and type M-w > >> 2. select the word "buffer" and type M-w > >> 3. type M-y M-p > >> > >> The minibuffer looks like: > >> > >> Yank from kill-ring: This > >> > >> but should be > >> > >> Yank from kill-ring: buffer > > > > So you don't like that M-p yields "This" and M-n yield "buffer" in > > this case? Why not? IOW, why did you expect M-p to yield "buffer"? > > This is M-y, not C-y. > > But this is not 'M-y C-y'. The logic is the following: > one key (either non-minibuffer 'C-y' or minibuffer 'M-y') should yank the last item, > two keys (non-minibuffer 'C-y M-y') should yank the second last item. That's your logic, not necessarily that of others. There's no "M-y M-y" with a preceding C-y, so I don't see any problem in the current behavior: it can be easily described in the documentation, and feels natural to me. But if you want to change it to the behavior you expect, I don't mind. Just do that (and the setting of the kill-ring pointer) soon, because currently the documentation of the new behavior of M-y in the manual is incomplete, and I'd like to complete it before I forget. Thanks. ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#48478: 28.0.50; yank-from-kill-ring and kill-ring-yank-pointer 2021-06-03 6:19 ` Eli Zaretskii @ 2021-06-03 20:55 ` Juri Linkov 2021-06-04 5:57 ` Eli Zaretskii 0 siblings, 1 reply; 49+ messages in thread From: Juri Linkov @ 2021-06-03 20:55 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 48478 > But if you want to change it to the behavior you expect, I don't mind. > Just do that It really looked like a bug, so I fixed it now. > (and the setting of the kill-ring pointer) soon, because > currently the documentation of the new behavior of M-y in the manual > is incomplete, and I'd like to complete it before I forget. Sorry, I forgot what is the setting of the kill-ring pointer? That needs to be fixed as well? ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#48478: 28.0.50; yank-from-kill-ring and kill-ring-yank-pointer 2021-06-03 20:55 ` Juri Linkov @ 2021-06-04 5:57 ` Eli Zaretskii 2021-06-04 16:46 ` Juri Linkov 0 siblings, 1 reply; 49+ messages in thread From: Eli Zaretskii @ 2021-06-04 5:57 UTC (permalink / raw) To: Juri Linkov; +Cc: 48478 > From: Juri Linkov <juri@linkov.net> > Cc: 48478@debbugs.gnu.org > Date: Thu, 03 Jun 2021 23:55:01 +0300 > > > (and the setting of the kill-ring pointer) soon, because > > currently the documentation of the new behavior of M-y in the manual > > is incomplete, and I'd like to complete it before I forget. > > Sorry, I forgot what is the setting of the kill-ring pointer? > That needs to be fixed as well? In the following use case: M-y <type something> TAB (1) <edit the completion> (2) RET C-y the last C-y inserts neither the unedited completion in (1) nor the edited one in (2). It inserts something else. It should insert one of these two, IMO, otherwise this behaves very different from C-y M-y M-y ... C-y ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#48478: 28.0.50; yank-from-kill-ring and kill-ring-yank-pointer 2021-06-04 5:57 ` Eli Zaretskii @ 2021-06-04 16:46 ` Juri Linkov 2021-06-04 19:04 ` Eli Zaretskii 0 siblings, 1 reply; 49+ messages in thread From: Juri Linkov @ 2021-06-04 16:46 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 48478 > In the following use case: > > M-y > <type something> > TAB (1) > <edit the completion> (2) > RET > C-y > > the last C-y inserts neither the unedited completion in (1) nor the > edited one in (2). It inserts something else. It should insert one > of these two, IMO, otherwise this behaves very different from > > C-y > M-y > M-y > ... > C-y 'C-y M-y M-y ... C-y' has no ability to edit the previous string, so these cases are not comparable. ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#48478: 28.0.50; yank-from-kill-ring and kill-ring-yank-pointer 2021-06-04 16:46 ` Juri Linkov @ 2021-06-04 19:04 ` Eli Zaretskii 2021-06-05 21:35 ` Juri Linkov 0 siblings, 1 reply; 49+ messages in thread From: Eli Zaretskii @ 2021-06-04 19:04 UTC (permalink / raw) To: Juri Linkov; +Cc: 48478 > From: Juri Linkov <juri@linkov.net> > Cc: 48478@debbugs.gnu.org > Date: Fri, 04 Jun 2021 19:46:00 +0300 > > > In the following use case: > > > > M-y > > <type something> > > TAB (1) > > <edit the completion> (2) > > RET > > C-y > > > > the last C-y inserts neither the unedited completion in (1) nor the > > edited one in (2). It inserts something else. It should insert one > > of these two, IMO, otherwise this behaves very different from > > > > C-y > > M-y > > M-y > > ... > > C-y > > 'C-y M-y M-y ... C-y' has no ability to edit the previous string, > so these cases are not comparable. You are missing the point. The point is to tell the user what to expect from the next C-y after a series of M-y's. It makes little sense to me to tell them the editing case behaves radically differently from the non-editing case. But if you still disagree, I give up: you win. The manual will remain in its current form, and will not say what happens with the kill-ring pointer in this case. ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#48478: 28.0.50; yank-from-kill-ring and kill-ring-yank-pointer 2021-06-04 19:04 ` Eli Zaretskii @ 2021-06-05 21:35 ` Juri Linkov 2021-06-06 5:52 ` Eli Zaretskii 0 siblings, 1 reply; 49+ messages in thread From: Juri Linkov @ 2021-06-05 21:35 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 48478 >> > In the following use case: >> > >> > M-y >> > <type something> >> > TAB (1) >> > <edit the completion> (2) >> > RET >> > C-y >> > >> > the last C-y inserts neither the unedited completion in (1) nor the >> > edited one in (2). It inserts something else. It should insert one >> > of these two, IMO, otherwise this behaves very different from >> > >> > C-y >> > M-y >> > M-y >> > ... >> > C-y >> >> 'C-y M-y M-y ... C-y' has no ability to edit the previous string, >> so these cases are not comparable. > > You are missing the point. The point is to tell the user what to > expect from the next C-y after a series of M-y's. It makes little > sense to me to tell them the editing case behaves radically > differently from the non-editing case. > > But if you still disagree, I give up: you win. The manual will remain > in its current form, and will not say what happens with the kill-ring > pointer in this case. I don't disagree. I simply don't know what to do. For example, above you said to insert one of these two, but which one and how is completely unclear. So it seems we need to hear more opinions. ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#48478: 28.0.50; yank-from-kill-ring and kill-ring-yank-pointer 2021-06-05 21:35 ` Juri Linkov @ 2021-06-06 5:52 ` Eli Zaretskii 2021-06-06 20:52 ` Juri Linkov 0 siblings, 1 reply; 49+ messages in thread From: Eli Zaretskii @ 2021-06-06 5:52 UTC (permalink / raw) To: Juri Linkov; +Cc: 48478 > From: Juri Linkov <juri@linkov.net> > Cc: 48478@debbugs.gnu.org > Date: Sun, 06 Jun 2021 00:35:58 +0300 > > I don't disagree. I simply don't know what to do. For example, > above you said to insert one of these two, but which one and how > is completely unclear. So it seems we need to hear more opinions. I think the conclusion up-thread was that if the entry is edited before it's inserted, then the edited entry should be added to the head of the kill-ring, and the pointer set there. IOW, if I edit the previous kill and insert it, the edited string becomes the one I get on the next C-y. The discussion concluded that doing this is possible without extensive changes, whereas the other alternative is "hard" as it goes against the current design and implementation of the functions involved in this. I'm okay with this behavior, and it is easy to describe in the manual and easy to remember. ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#48478: 28.0.50; yank-from-kill-ring and kill-ring-yank-pointer 2021-06-06 5:52 ` Eli Zaretskii @ 2021-06-06 20:52 ` Juri Linkov 2021-06-07 12:16 ` Eli Zaretskii 0 siblings, 1 reply; 49+ messages in thread From: Juri Linkov @ 2021-06-06 20:52 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 48478 > I think the conclusion up-thread was that if the entry is edited > before it's inserted, then the edited entry should be added to the > head of the kill-ring, and the pointer set there. IOW, if I edit the > previous kill and insert it, the edited string becomes the one I get > on the next C-y. The discussion concluded that doing this is possible > without extensive changes, whereas the other alternative is "hard" as > it goes against the current design and implementation of the functions > involved in this. I'm okay with this behavior, and it is easy to > describe in the manual and easy to remember. I'm still unsure why the command that only yanks text should add new text to the kill-ring. This goes against the logic of yanking because currently only killing commands can add text to the kill-ring. So it would be very strange to call 'kill-new' from 'yank-from-kill-ring': diff --git a/lisp/simple.el b/lisp/simple.el index 9e827320f1..1aa720edba 100644 --- a/lisp/simple.el +++ b/lisp/simple.el @@ -5781,8 +5781,9 @@ yank-from-kill-ring (insert-for-yank string) (when yank-from-kill-ring-rotate (let ((pos (seq-position kill-ring string))) - (when pos - (setq kill-ring-yank-pointer (nthcdr pos kill-ring))))) + (if pos + (setq kill-ring-yank-pointer (nthcdr pos kill-ring)) + (kill-new string)))) (if (consp arg) ;; Swap point and mark like in `yank' and `yank-pop'. (goto-char (prog1 (mark t) ^ permalink raw reply related [flat|nested] 49+ messages in thread
* bug#48478: 28.0.50; yank-from-kill-ring and kill-ring-yank-pointer 2021-06-06 20:52 ` Juri Linkov @ 2021-06-07 12:16 ` Eli Zaretskii 2021-06-08 16:55 ` Juri Linkov 0 siblings, 1 reply; 49+ messages in thread From: Eli Zaretskii @ 2021-06-07 12:16 UTC (permalink / raw) To: Juri Linkov; +Cc: 48478 > From: Juri Linkov <juri@linkov.net> > Cc: 48478@debbugs.gnu.org > Date: Sun, 06 Jun 2021 23:52:17 +0300 > > I'm still unsure why the command that only yanks text > should add new text to the kill-ring. This goes against > the logic of yanking because currently only killing commands > can add text to the kill-ring. That's not true: C-y adds to the kill-ring text that it finds in the clipboard. So there's nothing new or particularly surprising here, IMO. ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#48478: 28.0.50; yank-from-kill-ring and kill-ring-yank-pointer 2021-06-07 12:16 ` Eli Zaretskii @ 2021-06-08 16:55 ` Juri Linkov 2021-06-10 12:07 ` Eli Zaretskii 0 siblings, 1 reply; 49+ messages in thread From: Juri Linkov @ 2021-06-08 16:55 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 48478 tags 48478 fixed close 48478 28.0.50 thanks >> I'm still unsure why the command that only yanks text >> should add new text to the kill-ring. This goes against >> the logic of yanking because currently only killing commands >> can add text to the kill-ring. > > That's not true: C-y adds to the kill-ring text that it finds in the > clipboard. So there's nothing new or particularly surprising here, > IMO. Sorry, I forgot that C-y adds text to the kill-ring. So I changed yank-from-kill-ring to add an edited string to the kill-ring. ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#48478: 28.0.50; yank-from-kill-ring and kill-ring-yank-pointer 2021-06-08 16:55 ` Juri Linkov @ 2021-06-10 12:07 ` Eli Zaretskii 2021-06-11 17:10 ` Juri Linkov 0 siblings, 1 reply; 49+ messages in thread From: Eli Zaretskii @ 2021-06-10 12:07 UTC (permalink / raw) To: Juri Linkov; +Cc: 48478 > From: Juri Linkov <juri@linkov.net> > Cc: 48478@debbugs.gnu.org > Date: Tue, 08 Jun 2021 19:55:16 +0300 > > Sorry, I forgot that C-y adds text to the kill-ring. So I changed > yank-from-kill-ring to add an edited string to the kill-ring. Thanks, I therefore finalized the documentation of the new behavior of M-y. ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#48478: 28.0.50; yank-from-kill-ring and kill-ring-yank-pointer 2021-06-10 12:07 ` Eli Zaretskii @ 2021-06-11 17:10 ` Juri Linkov 2021-06-11 18:06 ` Eli Zaretskii 0 siblings, 1 reply; 49+ messages in thread From: Juri Linkov @ 2021-06-11 17:10 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 48478 >> Sorry, I forgot that C-y adds text to the kill-ring. So I changed >> yank-from-kill-ring to add an edited string to the kill-ring. > > Thanks, I therefore finalized the documentation of the new behavior of > M-y. I have only one minor remark for this text: "you can use completion commands to complete on an entry from the list of entries" It's unclear what "an entry" does mean in case of 'M-y TAB' that displays the list of all entries. ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#48478: 28.0.50; yank-from-kill-ring and kill-ring-yank-pointer 2021-06-11 17:10 ` Juri Linkov @ 2021-06-11 18:06 ` Eli Zaretskii 2021-06-11 18:33 ` Juri Linkov 2021-06-11 19:16 ` Eli Zaretskii 0 siblings, 2 replies; 49+ messages in thread From: Eli Zaretskii @ 2021-06-11 18:06 UTC (permalink / raw) To: Juri Linkov; +Cc: 48478 > From: Juri Linkov <juri@linkov.net> > Cc: 48478@debbugs.gnu.org > Date: Fri, 11 Jun 2021 20:10:01 +0300 > > "you can use completion commands to complete on an entry from the list of entries" > > It's unclear what "an entry" does mean in case of 'M-y TAB' > that displays the list of all entries. What exactly is unclear here? "An entry" is on of the "entries" from the list, what else? ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#48478: 28.0.50; yank-from-kill-ring and kill-ring-yank-pointer 2021-06-11 18:06 ` Eli Zaretskii @ 2021-06-11 18:33 ` Juri Linkov 2021-06-11 19:23 ` Eli Zaretskii 2021-06-11 19:16 ` Eli Zaretskii 1 sibling, 1 reply; 49+ messages in thread From: Juri Linkov @ 2021-06-11 18:33 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 48478 >> "you can use completion commands to complete on an entry from the list of entries" >> >> It's unclear what "an entry" does mean in case of 'M-y TAB' >> that displays the list of all entries. > > What exactly is unclear here? "An entry" is on of the "entries" from > the list, what else? I don't know, maybe everything already is correct here. ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#48478: 28.0.50; yank-from-kill-ring and kill-ring-yank-pointer 2021-06-11 18:33 ` Juri Linkov @ 2021-06-11 19:23 ` Eli Zaretskii 0 siblings, 0 replies; 49+ messages in thread From: Eli Zaretskii @ 2021-06-11 19:23 UTC (permalink / raw) To: Juri Linkov; +Cc: 48478 > From: Juri Linkov <juri@linkov.net> > Cc: 48478@debbugs.gnu.org > Date: Fri, 11 Jun 2021 21:33:51 +0300 > > >> "you can use completion commands to complete on an entry from the list of entries" > >> > >> It's unclear what "an entry" does mean in case of 'M-y TAB' > >> that displays the list of all entries. > > > > What exactly is unclear here? "An entry" is on of the "entries" from > > the list, what else? > > I don't know, maybe everything already is correct here. But something did confuse you. What was that? ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#48478: 28.0.50; yank-from-kill-ring and kill-ring-yank-pointer 2021-06-11 18:06 ` Eli Zaretskii 2021-06-11 18:33 ` Juri Linkov @ 2021-06-11 19:16 ` Eli Zaretskii 1 sibling, 0 replies; 49+ messages in thread From: Eli Zaretskii @ 2021-06-11 19:16 UTC (permalink / raw) To: juri; +Cc: 48478 > Date: Fri, 11 Jun 2021 21:06:37 +0300 > From: Eli Zaretskii <eliz@gnu.org> > Cc: 48478@debbugs.gnu.org > > What exactly is unclear here? "An entry" is on of the "entries" from > the list, what else? ^^ Should have been "one", sorry. ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#48478: 28.0.50; yank-from-kill-ring and kill-ring-yank-pointer 2021-05-20 19:56 ` Juri Linkov 2021-05-20 20:10 ` Eli Zaretskii @ 2021-05-30 22:23 ` Juri Linkov 2021-05-31 12:04 ` Eli Zaretskii 1 sibling, 1 reply; 49+ messages in thread From: Juri Linkov @ 2021-05-30 22:23 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 48478 > After inserting the edited entry it resets the kill-ring-yank-pointer > for the same reason why the kill-ring-yank-pointer gets reset > when a new entry gets added to the kill-ring after C-w, > i.e. like this line in 'kill-new': > > (setq kill-ring-yank-pointer kill-ring) BTW, bug#21199 asked to remove the above line from 'kill-new', so C-w could keep the old value of 'kill-ring-yank-pointer'. Maybe this should be optional? ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#48478: 28.0.50; yank-from-kill-ring and kill-ring-yank-pointer 2021-05-30 22:23 ` Juri Linkov @ 2021-05-31 12:04 ` Eli Zaretskii 2021-05-31 20:17 ` Juri Linkov 0 siblings, 1 reply; 49+ messages in thread From: Eli Zaretskii @ 2021-05-31 12:04 UTC (permalink / raw) To: Juri Linkov; +Cc: 48478 > From: Juri Linkov <juri@linkov.net> > Cc: 48478@debbugs.gnu.org > Date: Mon, 31 May 2021 01:23:54 +0300 > > > After inserting the edited entry it resets the kill-ring-yank-pointer > > for the same reason why the kill-ring-yank-pointer gets reset > > when a new entry gets added to the kill-ring after C-w, > > i.e. like this line in 'kill-new': > > > > (setq kill-ring-yank-pointer kill-ring) > > BTW, bug#21199 asked to remove the above line from 'kill-new', > so C-w could keep the old value of 'kill-ring-yank-pointer'. > Maybe this should be optional? Doesn't the new behavior of M-y fill that niche, albeit by other means? ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#48478: 28.0.50; yank-from-kill-ring and kill-ring-yank-pointer 2021-05-31 12:04 ` Eli Zaretskii @ 2021-05-31 20:17 ` Juri Linkov 2021-06-01 12:12 ` Eli Zaretskii 0 siblings, 1 reply; 49+ messages in thread From: Juri Linkov @ 2021-05-31 20:17 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 48478 >> > After inserting the edited entry it resets the kill-ring-yank-pointer >> > for the same reason why the kill-ring-yank-pointer gets reset >> > when a new entry gets added to the kill-ring after C-w, >> > i.e. like this line in 'kill-new': >> > >> > (setq kill-ring-yank-pointer kill-ring) >> >> BTW, bug#21199 asked to remove the above line from 'kill-new', >> so C-w could keep the old value of 'kill-ring-yank-pointer'. >> Maybe this should be optional? > > Doesn't the new behavior of M-y fill that niche, albeit by other > means? The minibuffer version of M-y doesn't reset the pointer anymore indeed. But users who prefer the non-minibuffer version of M-y still have this problem. ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#48478: 28.0.50; yank-from-kill-ring and kill-ring-yank-pointer 2021-05-31 20:17 ` Juri Linkov @ 2021-06-01 12:12 ` Eli Zaretskii 0 siblings, 0 replies; 49+ messages in thread From: Eli Zaretskii @ 2021-06-01 12:12 UTC (permalink / raw) To: Juri Linkov; +Cc: 48478 > From: Juri Linkov <juri@linkov.net> > Cc: 48478@debbugs.gnu.org > Date: Mon, 31 May 2021 23:17:12 +0300 > > >> > After inserting the edited entry it resets the kill-ring-yank-pointer > >> > for the same reason why the kill-ring-yank-pointer gets reset > >> > when a new entry gets added to the kill-ring after C-w, > >> > i.e. like this line in 'kill-new': > >> > > >> > (setq kill-ring-yank-pointer kill-ring) > >> > >> BTW, bug#21199 asked to remove the above line from 'kill-new', > >> so C-w could keep the old value of 'kill-ring-yank-pointer'. > >> Maybe this should be optional? > > > > Doesn't the new behavior of M-y fill that niche, albeit by other > > means? > > The minibuffer version of M-y doesn't reset the pointer anymore indeed. > But users who prefer the non-minibuffer version of M-y still have this problem. We introduced what you call "the minibuffer version" for this and similar use cases, so users who want this feature can invoke that version of M-y. So I think we now provide ample solution for that problem, albeit a different one from the one envisioned there. ^ permalink raw reply [flat|nested] 49+ messages in thread
end of thread, other threads:[~2021-06-11 19:23 UTC | newest] Thread overview: 49+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2021-05-17 11:34 bug#48478: 28.0.50; yank-from-kill-ring and kill-ring-yank-pointer Eli Zaretskii 2021-05-17 14:35 ` Lars Ingebrigtsen 2021-05-17 21:10 ` Juri Linkov 2021-05-18 11:51 ` Eli Zaretskii 2021-05-18 20:24 ` Juri Linkov 2021-05-19 2:30 ` Eli Zaretskii 2021-05-19 16:31 ` Juri Linkov 2021-05-20 9:32 ` Eli Zaretskii 2021-05-20 18:02 ` Juri Linkov 2021-05-20 19:04 ` Eli Zaretskii 2021-05-20 19:56 ` Juri Linkov 2021-05-20 20:10 ` Eli Zaretskii 2021-05-20 20:44 ` Juri Linkov 2021-05-21 5:51 ` Eli Zaretskii 2021-05-21 18:18 ` Juri Linkov 2021-05-22 6:41 ` Eli Zaretskii 2021-05-22 20:59 ` Juri Linkov 2021-05-23 7:19 ` Eli Zaretskii 2021-05-25 20:35 ` Juri Linkov 2021-05-26 12:05 ` Eli Zaretskii 2021-05-26 22:09 ` Juri Linkov 2021-05-27 7:30 ` Eli Zaretskii 2021-05-30 22:32 ` Juri Linkov 2021-05-31 12:08 ` Eli Zaretskii 2021-05-31 20:20 ` Juri Linkov 2021-06-01 12:13 ` Eli Zaretskii 2021-06-01 20:32 ` Juri Linkov 2021-06-02 14:57 ` Eli Zaretskii 2021-06-02 21:10 ` Juri Linkov 2021-06-03 6:19 ` Eli Zaretskii 2021-06-03 20:55 ` Juri Linkov 2021-06-04 5:57 ` Eli Zaretskii 2021-06-04 16:46 ` Juri Linkov 2021-06-04 19:04 ` Eli Zaretskii 2021-06-05 21:35 ` Juri Linkov 2021-06-06 5:52 ` Eli Zaretskii 2021-06-06 20:52 ` Juri Linkov 2021-06-07 12:16 ` Eli Zaretskii 2021-06-08 16:55 ` Juri Linkov 2021-06-10 12:07 ` Eli Zaretskii 2021-06-11 17:10 ` Juri Linkov 2021-06-11 18:06 ` Eli Zaretskii 2021-06-11 18:33 ` Juri Linkov 2021-06-11 19:23 ` Eli Zaretskii 2021-06-11 19:16 ` Eli Zaretskii 2021-05-30 22:23 ` Juri Linkov 2021-05-31 12:04 ` Eli Zaretskii 2021-05-31 20:17 ` Juri Linkov 2021-06-01 12:12 ` Eli Zaretskii
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.