all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#27442: Un-obsolete x-clipboard-yank, or provide analogous functional
@ 2017-06-21 14:29 Constantine Kharlamov
  2017-06-21 19:10 ` Eli Zaretskii
  0 siblings, 1 reply; 16+ messages in thread
From: Constantine Kharlamov @ 2017-06-21 14:29 UTC (permalink / raw)
  To: 27442

Emacs says: "x-clipboard-yank is obsolete since 25.1; use ‘clipboard-yank’ instead." The problem is that clipboard-yank doesn't work same way as x-clipboard-yank does.

x-clipboard-yank always uses clipboard content, which is exactly what I need. I.e. if I set (setq select-enable-clipboard nil) to not clutter my clipboard with kills, I only get content from the clipboard. (don't get me wrong, kill-ring is very cool, and I extensively use it in evil-mode. But I prefer to explicitly point when I want a content in the clipboard, which happens an order of magnitude rarer than usage of kill-ring).

clipboard-yank uses a kill-ring instead. So if I set (setq select-enable-clipboard nil), every usage of the function gives me a random text that may or may not be in the clipboard.





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

* bug#27442: Un-obsolete x-clipboard-yank, or provide analogous functional
  2017-06-21 14:29 bug#27442: Un-obsolete x-clipboard-yank, or provide analogous functional Constantine Kharlamov
@ 2017-06-21 19:10 ` Eli Zaretskii
  2017-06-21 19:55   ` Constantine Kharlamov
  0 siblings, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2017-06-21 19:10 UTC (permalink / raw)
  To: Constantine Kharlamov; +Cc: 27442

> From: Constantine Kharlamov <Hi-Angel@yandex.ru>
> Date: Wed, 21 Jun 2017 17:29:40 +0300
> 
> x-clipboard-yank always uses clipboard content, which is exactly what I need. I.e. if I set (setq select-enable-clipboard nil) to not clutter my clipboard with kills, I only get content from the clipboard. (don't get me wrong, kill-ring is very cool, and I extensively use it in evil-mode. But I prefer to explicitly point when I want a content in the clipboard, which happens an order of magnitude rarer than usage of kill-ring).
> 
> clipboard-yank uses a kill-ring instead.

I see the same call to 'yank' in both clipboard-yank and
x-clipboard-yank, so I'm not sure I understand what difference in
behavior you see (you also didn't say which version of Emacs did you
use).  Can you show a reproducible recipe starting from "emacs -Q"
which could be used to see the problem?

Thanks.





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

* bug#27442: Un-obsolete x-clipboard-yank, or provide analogous functional
  2017-06-21 19:10 ` Eli Zaretskii
@ 2017-06-21 19:55   ` Constantine Kharlamov
  2021-07-05 14:13     ` Lars Ingebrigtsen
  0 siblings, 1 reply; 16+ messages in thread
From: Constantine Kharlamov @ 2017-06-21 19:55 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 27442

On 21.06.2017 22:10, Eli Zaretskii wrote:
>> From: Constantine Kharlamov <Hi-Angel@yandex.ru>
>> Date: Wed, 21 Jun 2017 17:29:40 +0300
>>
>> x-clipboard-yank always uses clipboard content, which is exactly what I need. I.e. if I set (setq select-enable-clipboard nil) to not clutter my clipboard with kills, I only get content from the clipboard. (don't get me wrong, kill-ring is very cool, and I extensively use it in evil-mode. But I prefer to explicitly point when I want a content in the clipboard, which happens an order of magnitude rarer than usage of kill-ring).
>>
>> clipboard-yank uses a kill-ring instead.
> 
> I see the same call to 'yank' in both clipboard-yank and
> x-clipboard-yank, so I'm not sure I understand what difference in
> behavior you see (you also didn't say which version of Emacs did you
> use).

Sorry. It's 26.0.50, Archlinux, emacs-gitᴬᵁᴿ. However the first time I saw the problem at least 1.5 year ago on Ubuntu. It's just that I never reported, but today I started worrying.

> Can you show a reproducible recipe starting from "emacs -Q"
> which could be used to see the problem?
> 
> Thanks.

Well, for collecting the steps turned out `(clipboard-yank)` might have another subtle bug. But what I said still holds. Steps:

1. start `emacs -Q`
2. Press M-: to execute `(setq select-enable-clipboard nil)`
3. Copy a text in the system, i.e. outside of Emacs.
4. Press M-: to execute `(clipboard-yank)` (you'll get at the point a content from system clipboard)
5. Press M-< M-d (so now you have the word ";; This" in kill-ring)
6. Press M-: to execute `(clipboard-yank)`

	You will see ";; This" got pasted at point, not the value in the system clipboard.

7. Press M-: to execute `(x-clipboard-yank)`

	You will see content from the system clipboard got pasted at point.

The subtle bug I just found is an inconsistent behavior: if you skip the 4-th step, then at 6-th step you'll see the content from system clipboard. Which is actually what I'd want (i.e. the system clipboard content, not the inconsistent behavior, of course), but in long-term usage it pastes from kill-ring.





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

* bug#27442: Un-obsolete x-clipboard-yank, or provide analogous functional
  2017-06-21 19:55   ` Constantine Kharlamov
@ 2021-07-05 14:13     ` Lars Ingebrigtsen
  2021-07-05 14:46       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 16+ messages in thread
From: Lars Ingebrigtsen @ 2021-07-05 14:13 UTC (permalink / raw)
  To: Constantine Kharlamov; +Cc: Stefan Monnier, 27442

Constantine Kharlamov <Hi-Angel@yandex.ru> writes:

> 1. start `emacs -Q`
> 2. Press M-: to execute `(setq select-enable-clipboard nil)`
> 3. Copy a text in the system, i.e. outside of Emacs.
> 4. Press M-: to execute `(clipboard-yank)` (you'll get at the point a
> content from system clipboard)
> 5. Press M-< M-d (so now you have the word ";; This" in kill-ring)
> 6. Press M-: to execute `(clipboard-yank)`
>
> 	You will see ";; This" got pasted at point, not the value in
> the system clipboard.
>
> 7. Press M-: to execute `(x-clipboard-yank)`
>
> 	You will see content from the system clipboard got pasted at point.

Aaah!  This explains the weird behaviour I've been seeing when I'm
trying to paste stuff from the clipboard -- as you say,
`M-x clipboard-yank' doesn't work reliably if you've yanked the
clipboard contents once.

And that's because of this:

(defun gui-selection-value ()
  (let ((clip-text
         (when select-enable-clipboard
           (let ((text (gui--selection-value-internal 'CLIPBOARD)))
             (if (string= text "") (setq text nil))

             ;; Check the CLIPBOARD selection for 'newness', is it different
             ;; from what we remembered them to be last time we did a
             ;; cut/paste operation.
             (prog1
                 (unless (equal text gui--last-selected-text-clipboard)
                   text)
               (setq gui--last-selected-text-clipboard text)))))

So, indeed, if you `M-x clipboard-yank', then kill some text in Emacs,
you can't `M-x clipboard-yank' until you've clipboarded some other text,
yanked it, and then clipboarded the original text again.

Fixing this should be pretty trivial -- the following patch should do
the trick, I think (although I haven't tested it).  But I'm not quite
sure about the intended logic here, so I've added Stefan M to the CCs --
perhaps he has some comments.

diff --git a/lisp/menu-bar.el b/lisp/menu-bar.el
index 739e751d8a..dac04e113e 100644
--- a/lisp/menu-bar.el
+++ b/lisp/menu-bar.el
@@ -570,7 +570,8 @@ menu-bar-edit-menu
 (defun clipboard-yank ()
   "Insert the clipboard contents, or the last stretch of killed text."
   (interactive "*")
-  (let ((select-enable-clipboard t))
+  (let ((select-enable-clipboard t)
+        (gui--last-selected-text-clipboard nil))
     (yank)))
 
 (defun clipboard-kill-ring-save (beg end &optional region)


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





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

* bug#27442: Un-obsolete x-clipboard-yank, or provide analogous functional
  2021-07-05 14:13     ` Lars Ingebrigtsen
@ 2021-07-05 14:46       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2021-07-05 15:28         ` Lars Ingebrigtsen
  0 siblings, 1 reply; 16+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2021-07-05 14:46 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Eli Zaretskii, 27442, Constantine Kharlamov

> (defun gui-selection-value ()
>   (let ((clip-text
>          (when select-enable-clipboard
>            (let ((text (gui--selection-value-internal 'CLIPBOARD)))
>              (if (string= text "") (setq text nil))
>
>              ;; Check the CLIPBOARD selection for 'newness', is it different
>              ;; from what we remembered them to be last time we did a
>              ;; cut/paste operation.
>              (prog1
>                  (unless (equal text gui--last-selected-text-clipboard)
>                    text)
>                (setq gui--last-selected-text-clipboard text)))))
>
> So, indeed, if you `M-x clipboard-yank', then kill some text in Emacs,
> you can't `M-x clipboard-yank' until you've clipboarded some other text,
> yanked it, and then clipboarded the original text again.
>
> Fixing this should be pretty trivial -- the following patch should do
> the trick, I think (although I haven't tested it).  But I'm not quite
> sure about the intended logic here, so I've added Stefan M to the CCs --
> perhaps he has some comments.

AFAIK this part of the clipboard interaction is one I just preserved
from earlier code when I did my "gui-selection" rework.
I "just preserved" it because I don't really understand how it's
intended to work, nor do I understand enough of the design constraints
to be able to come up with my own design of how it should work :-(

Your patch looks acceptable to me (it is also disappointing because
it doesn't really help understand how this thing is intended to work,
but it follows the same principles as the ones I followed).


        Stefan






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

* bug#27442: Un-obsolete x-clipboard-yank, or provide analogous functional
  2021-07-05 14:46       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2021-07-05 15:28         ` Lars Ingebrigtsen
  2021-07-05 15:59           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2021-07-05 16:55           ` Eli Zaretskii
  0 siblings, 2 replies; 16+ messages in thread
From: Lars Ingebrigtsen @ 2021-07-05 15:28 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 27442, Constantine Kharlamov

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> AFAIK this part of the clipboard interaction is one I just preserved
> from earlier code when I did my "gui-selection" rework.
> I "just preserved" it because I don't really understand how it's
> intended to work, nor do I understand enough of the design constraints
> to be able to come up with my own design of how it should work :-(

*ponder* Well, I guess it's a vague kind of DWIM thing going on...
Since we don't have timestamps on our own kills, and
`select-enable-clipboard' defaults to t, we want to let a clipboard
selection "win" if we haven't yanked it before?  But...  it seems to me
like this is already handled by other logic when putting things on the
kill ring in the first place.

That is, if you "emacs -Q", put something on the clipboard from a
different programme, and when `M-w' something in Emacs, then `C-y' will
insert the latter.

I've tested various things here now, and I'm unable to come up with a
scenario where the current DWIM logic is helpful, really.

Anybody else able to deduce what the point of the code is?  And if they
do, can they put some comments in `gui-selection-value'?

> Your patch looks acceptable to me (it is also disappointing because
> it doesn't really help understand how this thing is intended to work,
> but it follows the same principles as the ones I followed).

:-)

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





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

* bug#27442: Un-obsolete x-clipboard-yank, or provide analogous functional
  2021-07-05 15:28         ` Lars Ingebrigtsen
@ 2021-07-05 15:59           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2021-07-05 16:55           ` Eli Zaretskii
  1 sibling, 0 replies; 16+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2021-07-05 15:59 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Eli Zaretskii, 27442, Constantine Kharlamov

> *ponder* Well, I guess it's a vague kind of DWIM thing going on...
> Since we don't have timestamps on our own kills, and
> `select-enable-clipboard' defaults to t, we want to let a clipboard
> selection "win" if we haven't yanked it before?  But...  it seems to me
> like this is already handled by other logic when putting things on the
> kill ring in the first place.

That pretty much matches my understanding, yes.

> That is, if you "emacs -Q", put something on the clipboard from a
> different programme, and when `M-w' something in Emacs, then `C-y' will
> insert the latter.

Yes, IIUC this is the easy case.  I think the harder case is when we
`M-w` first and then put something on the clipboard with another
application, then do `C-y`.

> I've tested various things here now, and I'm unable to come up with a
> scenario where the current DWIM logic is helpful, really.

Yet AFAICT the kill-ring logic was there already when the clipboard
logic was added, so I'm not sure the duplication is completely redundant.


        Stefan






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

* bug#27442: Un-obsolete x-clipboard-yank, or provide analogous functional
  2021-07-05 15:28         ` Lars Ingebrigtsen
  2021-07-05 15:59           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2021-07-05 16:55           ` Eli Zaretskii
  2021-07-05 20:11             ` Lars Ingebrigtsen
  1 sibling, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2021-07-05 16:55 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: monnier, 27442, Hi-Angel

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Constantine Kharlamov <Hi-Angel@yandex.ru>,  Eli Zaretskii
>  <eliz@gnu.org>,  27442@debbugs.gnu.org
> Date: Mon, 05 Jul 2021 17:28:02 +0200
> 
> *ponder* Well, I guess it's a vague kind of DWIM thing going on...
> Since we don't have timestamps on our own kills, and
> `select-enable-clipboard' defaults to t, we want to let a clipboard
> selection "win" if we haven't yanked it before?  But...  it seems to me
> like this is already handled by other logic when putting things on the
> kill ring in the first place.
> 
> That is, if you "emacs -Q", put something on the clipboard from a
> different programme, and when `M-w' something in Emacs, then `C-y' will
> insert the latter.
> 
> I've tested various things here now, and I'm unable to come up with a
> scenario where the current DWIM logic is helpful, really.

Please also try with save-interprogram-paste-before-kill non-nil.





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

* bug#27442: Un-obsolete x-clipboard-yank, or provide analogous functional
  2021-07-05 16:55           ` Eli Zaretskii
@ 2021-07-05 20:11             ` Lars Ingebrigtsen
  2021-07-05 20:24               ` Lars Ingebrigtsen
  2021-07-06 11:21               ` Eli Zaretskii
  0 siblings, 2 replies; 16+ messages in thread
From: Lars Ingebrigtsen @ 2021-07-05 20:11 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: monnier, 27442, Hi-Angel

Eli Zaretskii <eliz@gnu.org> writes:

> Please also try with save-interprogram-paste-before-kill non-nil.

As far as I can tell, that's not really affected by the code in
gui-selection-value, or vice versa.

But...  Hm...  poking at this a bit more:

When select-enable-clipboard is non-nil (the default), 

(kill-new "foo")
(gui--selection-value-internal 'CLIPBOARD)
=> "foo"
gui--last-selected-text-clipboard
=> "foo"

Because we're copying over the string to the clipboard.  So when we're
then yanking back, we're really trying to determine whether we ourselves
was responsible for putting the data on the clipboard, and if that's the
case, we want to ignore the data?  Because:

(kill-new "foo")
(gui-selection-value)
=> nil

Could we use a different way to identify this situation that's less
fragile?  Hm...  I don't really see any with our current low-level
functions.  I think x-get-selection-internal could have returned more
metadata -- the timestamp, for instance, which would have allowed us to
see whether we ourselves really pushed the data to the clipboard.

My analysis here may be wrong, but if this is the reason the code in
that function is the way it is, I think the right fix here is the
trivial patch I proposed, along with more comments in
`gui-selection-value' that explains what the point of the
duplicate-ignoring code is.

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





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

* bug#27442: Un-obsolete x-clipboard-yank, or provide analogous functional
  2021-07-05 20:11             ` Lars Ingebrigtsen
@ 2021-07-05 20:24               ` Lars Ingebrigtsen
  2021-07-06 11:21               ` Eli Zaretskii
  1 sibling, 0 replies; 16+ messages in thread
From: Lars Ingebrigtsen @ 2021-07-05 20:24 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: monnier, 27442, Hi-Angel

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Because we're copying over the string to the clipboard.  So when we're
> then yanking back, we're really trying to determine whether we ourselves
> was responsible for putting the data on the clipboard, and if that's the
> case, we want to ignore the data?  Because:
>
> (kill-new "foo")
> (gui-selection-value)
> => nil

If this is the reason for this check, then removing the setq of 
gui--last-selected-text-clipboard in gui-selection-value, and only set
it in gui-select-text, would fix this problem, too.  I think.

But it's late, and I may be misreading the code.  :-)

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





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

* bug#27442: Un-obsolete x-clipboard-yank, or provide analogous functional
  2021-07-05 20:11             ` Lars Ingebrigtsen
  2021-07-05 20:24               ` Lars Ingebrigtsen
@ 2021-07-06 11:21               ` Eli Zaretskii
  2021-07-06 14:18                 ` Lars Ingebrigtsen
  1 sibling, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2021-07-06 11:21 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: monnier, 27442, Hi-Angel

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: monnier@iro.umontreal.ca,  Hi-Angel@yandex.ru,  27442@debbugs.gnu.org
> Date: Mon, 05 Jul 2021 22:11:22 +0200
> 
> (kill-new "foo")
> (gui-selection-value)
> => nil
> 
> Could we use a different way to identify this situation that's less
> fragile?

AFAIK, there's no reasonable way of doing a better check.

> Hm...  I don't really see any with our current low-level
> functions.  I think x-get-selection-internal could have returned more
> metadata -- the timestamp, for instance, which would have allowed us to
> see whether we ourselves really pushed the data to the clipboard.

Where would that time stamp come from?

> My analysis here may be wrong, but if this is the reason the code in
> that function is the way it is, I think the right fix here is the
> trivial patch I proposed, along with more comments in
> `gui-selection-value' that explains what the point of the
> duplicate-ignoring code is.

I admit I don't really understand what the patch does and how.  can
you elaborate on that?






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

* bug#27442: Un-obsolete x-clipboard-yank, or provide analogous functional
  2021-07-06 11:21               ` Eli Zaretskii
@ 2021-07-06 14:18                 ` Lars Ingebrigtsen
  2021-07-06 15:45                   ` Eli Zaretskii
  0 siblings, 1 reply; 16+ messages in thread
From: Lars Ingebrigtsen @ 2021-07-06 14:18 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: monnier, 27442, Hi-Angel

Eli Zaretskii <eliz@gnu.org> writes:

>> Hm...  I don't really see any with our current low-level
>> functions.  I think x-get-selection-internal could have returned more
>> metadata -- the timestamp, for instance, which would have allowed us to
>> see whether we ourselves really pushed the data to the clipboard.
>
> Where would that time stamp come from?

Selections have time stamps, so we could compare the time stamp from
when we pushed the data onto the clipboard with what we have.  I think?
It's the timestamp parameter to/from
XSetSelectionOwner/XConvertSelection/x_get_window_property_as_lisp_data.

It's been years since I messed around with that stuff, so I could well
be misremembering what the meaning of the timestamps are.

>> My analysis here may be wrong, but if this is the reason the code in
>> that function is the way it is, I think the right fix here is the
>> trivial patch I proposed, along with more comments in
>> `gui-selection-value' that explains what the point of the
>> duplicate-ignoring code is.
>
> I admit I don't really understand what the patch does and how.  can
> you elaborate on that?

It just makes `M-x clipboard-yank' defeat the "check for duplicates"
logic and always return the contents of the clipboard.

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





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

* bug#27442: Un-obsolete x-clipboard-yank, or provide analogous functional
  2021-07-06 14:18                 ` Lars Ingebrigtsen
@ 2021-07-06 15:45                   ` Eli Zaretskii
  2021-07-06 16:20                     ` Lars Ingebrigtsen
  0 siblings, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2021-07-06 15:45 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: monnier, 27442, Hi-Angel

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: monnier@iro.umontreal.ca,  Hi-Angel@yandex.ru,  27442@debbugs.gnu.org
> Date: Tue, 06 Jul 2021 16:18:18 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Hm...  I don't really see any with our current low-level
> >> functions.  I think x-get-selection-internal could have returned more
> >> metadata -- the timestamp, for instance, which would have allowed us to
> >> see whether we ourselves really pushed the data to the clipboard.
> >
> > Where would that time stamp come from?
> 
> Selections have time stamps

In the clipboard? supported by all the systems and all the clipboard
varieties out there?

> so we could compare the time stamp from
> when we pushed the data onto the clipboard with what we have.  I think?

Is it reasonable to assume that close enough time stamps necessarily
mean we are the owner?

> > I admit I don't really understand what the patch does and how.  can
> > you elaborate on that?
> 
> It just makes `M-x clipboard-yank' defeat the "check for duplicates"
> logic and always return the contents of the clipboard.

But that would mean we throw away the baby together with the
bathwater, no?  Why would we want to do that?





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

* bug#27442: Un-obsolete x-clipboard-yank, or provide analogous functional
  2021-07-06 15:45                   ` Eli Zaretskii
@ 2021-07-06 16:20                     ` Lars Ingebrigtsen
  2021-07-06 17:15                       ` Eli Zaretskii
  0 siblings, 1 reply; 16+ messages in thread
From: Lars Ingebrigtsen @ 2021-07-06 16:20 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: monnier, 27442, Hi-Angel

Eli Zaretskii <eliz@gnu.org> writes:

> In the clipboard? supported by all the systems and all the clipboard
> varieties out there?

I don't know -- probably by the ones we care most about.

> Is it reasonable to assume that close enough time stamps necessarily
> mean we are the owner?

It's a millisecond timestamp on the clipboard -- so it's a better guess
than what we have.

>> It just makes `M-x clipboard-yank' defeat the "check for duplicates"
>> logic and always return the contents of the clipboard.
>
> But that would mean we throw away the baby together with the
> bathwater, no?  Why would we want to do that?

No, this is the command `M-x clipboard-yank' only, which should always
return the clipboard contents.  The DWIM stuff in this gui selection
function is for `C-y' and friends.

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





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

* bug#27442: Un-obsolete x-clipboard-yank, or provide analogous functional
  2021-07-06 16:20                     ` Lars Ingebrigtsen
@ 2021-07-06 17:15                       ` Eli Zaretskii
  2021-07-06 17:26                         ` Lars Ingebrigtsen
  0 siblings, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2021-07-06 17:15 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: monnier, 27442, Hi-Angel

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: monnier@iro.umontreal.ca,  Hi-Angel@yandex.ru,  27442@debbugs.gnu.org
> Date: Tue, 06 Jul 2021 18:20:30 +0200
> 
> >> It just makes `M-x clipboard-yank' defeat the "check for duplicates"
> >> logic and always return the contents of the clipboard.
> >
> > But that would mean we throw away the baby together with the
> > bathwater, no?  Why would we want to do that?
> 
> No, this is the command `M-x clipboard-yank' only, which should always
> return the clipboard contents.  The DWIM stuff in this gui selection
> function is for `C-y' and friends.

Ah, okay.  Then I guess your fix should be fine, thanks.





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

* bug#27442: Un-obsolete x-clipboard-yank, or provide analogous functional
  2021-07-06 17:15                       ` Eli Zaretskii
@ 2021-07-06 17:26                         ` Lars Ingebrigtsen
  0 siblings, 0 replies; 16+ messages in thread
From: Lars Ingebrigtsen @ 2021-07-06 17:26 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: monnier, 27442, Hi-Angel

Eli Zaretskii <eliz@gnu.org> writes:

> Ah, okay.  Then I guess your fix should be fine, thanks.

Pushed now (along with a comment that explains the DWIM action better).

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





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

end of thread, other threads:[~2021-07-06 17:26 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-06-21 14:29 bug#27442: Un-obsolete x-clipboard-yank, or provide analogous functional Constantine Kharlamov
2017-06-21 19:10 ` Eli Zaretskii
2017-06-21 19:55   ` Constantine Kharlamov
2021-07-05 14:13     ` Lars Ingebrigtsen
2021-07-05 14:46       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-07-05 15:28         ` Lars Ingebrigtsen
2021-07-05 15:59           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-07-05 16:55           ` Eli Zaretskii
2021-07-05 20:11             ` Lars Ingebrigtsen
2021-07-05 20:24               ` Lars Ingebrigtsen
2021-07-06 11:21               ` Eli Zaretskii
2021-07-06 14:18                 ` Lars Ingebrigtsen
2021-07-06 15:45                   ` Eli Zaretskii
2021-07-06 16:20                     ` Lars Ingebrigtsen
2021-07-06 17:15                       ` Eli Zaretskii
2021-07-06 17:26                         ` 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.