cut and paste not working after xdg-open "org-protocol://store-link?url=URL&title=TITLE"

cut and paste not working after xdg-open "org-protocol://store-link?url=URL&title=TITLE"

[chris]

[-- Attachment #1: Type: text/plain, Size: 1575 bytes --]

Hi people,


First: `xdg-open "org-protocol://store-link?url=URL&title=TITLE"` from a terminal.
Then `M-x org-insert-link` in emacs, or not (it makes no difference).
Then cut-and-paste from non-emacs-application (e.g., Kde's Konsole, or Firefox) to emacs.
When doing `C-y` what it pastes is "URL", not what I have copied from Firefox.
For it to work again: one cut-and-paste operation from emacs to emacs.
Then it works again until the next time.
Doing `C-k` is enough, but it's still cumbersome.


My compositor is Wayland. It was like this, before, with `emacs-pgtk` 28.0.50.
It is still like that with: GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 
3.24.31, cairo version 1.16.0) of 2022-01-26
System is debian sid upgraded just before.


Thanks,
Chris


PS: some XY-problem:
What sort of argument to pass to `org-protocol-store-link`.
When I do `(org-protocol-parse-parameters "url=U&title=T" t '(:url :title))` it works.
It works when I do `xdg-open "org-protocol://store-link?url=URL&title=TITLE"
` from a terminal.
But why is there a `nil` here:
https://github.com/emacs-mirror/emacs/blob/19dcb237/lisp/org/org-protocol.el#L467[1]
And why is it working at all from `xdg-open "org-protocol://store-link?
url=URL&title=TITLE"`, with a `nil` in that position?


Note: `(org-protocol-store-link "U/T")` works, `(org-protocol-store-link "url=U&title=T")` 
doesn't work. Produces link `[[url=U&title=T]]` instead of `[[U][T]]`.

--------
[1] https://github.com/emacs-mirror/emacs/blob/
19dcb237b5b02b36580294ab309124f346a66024/lisp/org/org-protocol.el#L467

[-- Attachment #2: Type: text/html, Size: 3854 bytes --]

Re: cut and paste not working after xdg-open "org-protocol://store-link?url=URL&title=TITLE"

[Max Nikulin]

On 27/01/2022 07:03, chris wrote:
> 
> First: `xdg-open "org-protocol://store-link?url=URL&title=TITLE"` from a 
> terminal.
> Then `M-x org-insert-link` in emacs, or not (it makes no difference).
> Then cut-and-paste from non-emacs-application (e.g., Kde's Konsole, or 
> Firefox) to emacs.
> When doing `C-y` what it pastes is "URL", not what I have copied from 
> Firefox.

Just a data point: I can not reproduce it with X11, emacs-26.3, and Org 
from git main HEAD. Maybe I will try with emacs-27 and Wayland in a few 
days.

emacs -Q -L ~/src/org-mode/lisp/ \
   -l org-protocol --eval '(server-start)' test.org
emacsclient 'org-protocol:/store-link?url=http://o.rg/&title=Tt1'
copy from firefox
C-y (org-yank) in Emacs pastes text that I copied from firefox.

In some aspects your problem looks similar to:

Max Nikulin. [PATCH] [BUG] org.el: Fix first call of `org-paste-subtree' 
Mon, 29 Nov 2021 19:02:35 +0700.
https://list.orgmode.org/so2fh1$10kj$1@ciao.gmane.io


> But why is there a `nil` here:
> 
> https://github.com/emacs-mirror/emacs/blob/19dcb237/lisp/org/org-protocol.el#L467 
> <https://github.com/emacs-mirror/emacs/blob/19dcb237b5b02b36580294ab309124f346a66024/lisp/org/org-protocol.el#L467>
> 
> And why is it working at all from `xdg-open 
> "org-protocol://store-link?url=URL&title=TITLE"`, with a `nil` in that 
> position?
> 
> Note: `(org-protocol-store-link "U/T")` works, `(org-protocol-store-link 
> "url=U&title=T")` doesn't work. Produces link `[[url=U&title=T]]` 
> instead of `[[U][T]]`.

What is the problem with nil there? New-style URIs are parsed before 
they are passed to subprotocol handlers. Why are you trying to call 
org-protocol-store-link directly?

Re: cut and paste not working after xdg-open "org-protocol://store-link?url=URL&title=TITLE"

[chris]

On Friday, 28 January 2022 13:40:45 CET Max Nikulin wrote:
> On 27/01/2022 07:03, chris wrote:
> > First: `xdg-open "org-protocol://store-link?url=URL&title=TITLE"` from a
> > terminal.
> > Then `M-x org-insert-link` in emacs, or not (it makes no difference).
> > Then cut-and-paste from non-emacs-application (e.g., Kde's Konsole, or
> > Firefox) to emacs.
> > When doing `C-y` what it pastes is "URL", not what I have copied from
> > Firefox.
> 
> Just a data point: I can not reproduce it with X11, emacs-26.3, and Org
> from git main HEAD. Maybe I will try with emacs-27 and Wayland in a few
> days.
> 
> emacs -Q -L ~/src/org-mode/lisp/ \
>    -l org-protocol --eval '(server-start)' test.org
> emacsclient 'org-protocol:/store-link?url=http://o.rg/&title=Tt1'
> copy from firefox
> C-y (org-yank) in Emacs pastes text that I copied from firefox.
> 
> In some aspects your problem looks similar to:
> 
> Max Nikulin. [PATCH] [BUG] org.el: Fix first call of `org-paste-subtree'
> Mon, 29 Nov 2021 19:02:35 +0700.
> https://list.orgmode.org/so2fh1$10kj$1@ciao.gmane.io

Yes, yes, possibly
Just something I've noticed, which is obvious, but I didn't thought about, and 
which has probably no bearing:
1- click on the bookmarklet
2- `C-c C-l Ret Ret` in an org-buffer, so the link is created (this step not 
necessary though)
3- if you do `C-y` you can see the URL is in the kill-ring
But obviously there is no reason for this URL to be also in the Wayland (or 
x11) clipboard? (there is no law of nature saying that what is in emacs kill-
ring must necessarily also be in wayland clipboard. I think there is a law of 
nature for the other way around though)
In any case, in the case of Kde/Kwin/Wayland, it is not copied in the Wayland 
clipboard.
Maybe it's in the description of org-protocol/store-link that the URL should 
be copied in emacs kill-ring, in any case, it is.
But no it doesn't show in the kde/wayland clipboard (and why would it).

> 
> > But why is there a `nil` here:
> > 
> > https://github.com/emacs-mirror/emacs/blob/19dcb237/lisp/org/org-protocol.
> > el#L467
> > <https://github.com/emacs-mirror/emacs/blob/19dcb237b5b02b36580294ab30912
> > 4f346a66024/lisp/org/org-protocol.el#L467>
> > 
> > And why is it working at all from `xdg-open
> > "org-protocol://store-link?url=URL&title=TITLE"`, with a `nil` in that
> > position?
> > 
> > Note: `(org-protocol-store-link "U/T")` works, `(org-protocol-store-link
> > "url=U&title=T")` doesn't work. Produces link `[[url=U&title=T]]`
> > instead of `[[U][T]]`.
> 
> What is the problem with nil there? New-style URIs are parsed before
> they are passed to subprotocol handlers. Why are you trying to call
> org-protocol-store-link directly?

Right, right, right
I was only trying to see if there was something obviously sticking out about 
the cut and paste issue.
So you say "new style URIs are parsed before they are passed to subprotocol 
handler": so, no worries then.
Thanks a lot for saying so. I've been searching but haven't found were they 
were parsed. I've probably haven't searched enough, and anyway it's of no 
bearing. Thanks again.

Re: cut and paste not working after xdg-open "org-protocol://store-link?url=URL&title=TITLE"

[Ihor Radchenko]

chris <inkbottle007@gmail.com> writes:

> 3- if you do `C-y` you can see the URL is in the kill-ring
> But obviously there is no reason for this URL to be also in the Wayland (or 
> x11) clipboard? (there is no law of nature saying that what is in emacs kill-
> ring must necessarily also be in wayland clipboard. I think there is a law of 
> nature for the other way around though)
> In any case, in the case of Kde/Kwin/Wayland, it is not copied in the Wayland 
> clipboard.
> Maybe it's in the description of org-protocol/store-link that the URL should 
> be copied in emacs kill-ring, in any case, it is.
> But no it doesn't show in the kde/wayland clipboard (and why would it).

I am not 100% sure if I understand your message clearly. However, just
letting you know about existence of the following Emacs customisations:

save-interprogram-paste-before-kill:
        Whether to save existing clipboard text into kill ring before replacing it.
select-enable-primary:
        Non-nil means cutting and pasting uses the primary selection.

Best,
Ihor

Re: cut and paste not working after xdg-open "org-protocol://store-link?url=URL&title=TITLE"

[Max Nikulin]

On 30/01/2022 10:12, chris wrote:
> 
> Yes, yes, possibly
> Just something I've noticed, which is obvious, but I didn't thought about, and
> which has probably no bearing:
> 1- click on the bookmarklet
> 2- `C-c C-l Ret Ret` in an org-buffer, so the link is created (this step not
> necessary though)
> 3- if you do `C-y` you can see the URL is in the kill-ring
> But obviously there is no reason for this URL to be also in the Wayland (or
> x11) clipboard? (there is no law of nature saying that what is in emacs kill-
> ring must necessarily also be in wayland clipboard. I think there is a law of
> nature for the other way around though)
> In any case, in the case of Kde/Kwin/Wayland, it is not copied in the Wayland
> clipboard.
> Maybe it's in the description of org-protocol/store-link that the URL should
> be copied in emacs kill-ring, in any case, it is.
> But no it doesn't show in the kde/wayland clipboard (and why would it).

Do you mean the following steps to reproduce behavior you have observed:

1. Copy something from any application, e.g. firefox
2. emacsclient 'org-protocol://store-link?url=http://o.rg/&title=Tt1'
3. Paste from CLIPBOARD

url from store link is inserted while you are expecting text copied in 
step 1.

After 2 emacs shows the following message:

> ‘M-x org-insert-link’ to insert new Org link, ‘C-y’ to insert "http://o.rg/"

So yanking the URL is expected behavior. I have never used this feature 
nor have been suffering from it. I do not know a reason behind this 
choice, maybe the developer implemented store-link decided that it is 
convenient.

Ihor pointed to variables that controls Emacs integration with desktop. 
See help for `kill-new' for more hints. I believe, it is reasonable that 
by default interaction with CLIPBOARD is enabled in Emacs. My complain 
is the opposite, there is no default key bindings for PRIMARY selection 
(in addition to CLIPBOARD, not instead of it). I had to look for keys 
that are not bound yet to add yank and kill to PRIMARY (as a side effect 
I added similar setup to bash).

As to org-store-link, desktop integration might be better as well, there 
is no text/html variant to paste link+description to application that 
supports rich text formatting. After org-store-link:

xclip -o -selection CLIPBOARD -target TARGETS
TIMESTAMP
MULTIPLE
TEXT
COMPOUND_TEXT
STRING
UTF8_STRING
TARGETS
LENGTH
DELETE
FILE_NAME
CHARACTER_POSITION
LINE_NUMBER
COLUMN_NUMBER
OWNER_OS
HOST_NAME
USER
CLASS
NAME
ATOM
INTEGER
SAVE_TARGETS

Notice that text/html is available when text containing a link is copied 
from firefox:

xclip -o -selection CLIPBOARD -target TARGETS
TIMESTAMP
TARGETS
MULTIPLE
SAVE_TARGETS
text/html
text/_moz_htmlcontext
text/_moz_htmlinfo
UTF8_STRING
COMPOUND_TEXT
TEXT
STRING
text/plain;charset=utf-8
text/plain
text/x-moz-url-priv

If you need both selection text and link URL than you may try 
org-protocol:/capture?body=B&title=T&url=U instead.

>>> But why is there a `nil` here:
>>>
>>> https://github.com/emacs-mirror/emacs/blob/19dcb237/lisp/org/org-protocol.
>>> el#L467
>>> <https://github.com/emacs-mirror/emacs/blob/19dcb237b5b02b36580294ab30912
>>> 4f346a66024/lisp/org/org-protocol.el#L467>
>>>
>>> And why is it working at all from `xdg-open
>>> "org-protocol://store-link?url=URL&title=TITLE"`, with a `nil` in that
>>> position?
>>>
>>> Note: `(org-protocol-store-link "U/T")` works, `(org-protocol-store-link
>>> "url=U&title=T")` doesn't work. Produces link `[[url=U&title=T]]`
>>> instead of `[[U][T]]`.
>>
>> What is the problem with nil there? New-style URIs are parsed before
>> they are passed to subprotocol handlers. Why are you trying to call
>> org-protocol-store-link directly?
> 
> Right, right, right
> I was only trying to see if there was something obviously sticking out about
> the cut and paste issue.

There is an explicit call of `kill-new' in `org-protocol-store-link'.

> So you say "new style URIs are parsed before they are passed to subprotocol
> handler": so, no worries then.
> Thanks a lot for saying so. I've been searching but haven't found were they
> were parsed. I've probably haven't searched enough, and anyway it's of no
> bearing. Thanks again.

https://git.savannah.gnu.org/cgit/emacs/org-mode.git/tree/lisp/org-protocol.el#n679

P.S. There is an issue with the kill ring that I do not like. If I yank 
something in CAPTURE buffer and then refile captured item, the latest 
entry of the kill ring is not the one that I just yanked, so it is 
necessary to press M-Y.

Re: cut and paste not working after xdg-open "org-protocol://store-link?url=URL&title=TITLE"

[chris]

[-- Attachment #1: Type: text/plain, Size: 2926 bytes --]

On Sunday, 30 January 2022 04:36:01 CET Ihor Radchenko wrote:
> chris <inkbottle007@gmail.com> writes:
> > 3- if you do `C-y` you can see the URL is in the kill-ring
> > But obviously there is no reason for this URL to be also in the Wayland
> > (or
> > x11) clipboard? (there is no law of nature saying that what is in emacs
> > kill- ring must necessarily also be in wayland clipboard. I think there
> > is a law of nature for the other way around though)
> > In any case, in the case of Kde/Kwin/Wayland, it is not copied in the
> > Wayland clipboard.
> > Maybe it's in the description of org-protocol/store-link that the URL
> > should be copied in emacs kill-ring, in any case, it is.
> > But no it doesn't show in the kde/wayland clipboard (and why would it).
> 
> I am not 100% sure if I understand your message clearly. However, just
> letting you know about existence of the following Emacs customisations:

It is, only, in conjunction with `org-protocol`, that kill-ring and Wayland-clipboard get out 
of sync.

Not in some general case. General case is fine.

But in the case of org-protocol, as described in the original post and not present in the 
excerpt you quoted, they do get out of sync.

To summarize again there are two things that are happening:

After doing `xdg-open "org-protocol://store-link?url=URL&title=TITLE"`.
The string "URL" is pushed into Emacs kill-ring.
But, this very string "URL", is not inserted into Wayland clipboard.

That was the first thing, string pushed into kill-ring, but not pushed simultaneously, into 
Wayland clipboard.

Now second thing: from that point onward, the other way around is broken. (And that is 
the part that is really annoying.)

[Then] I mouse-select a string in Firefox, or any application not Emacs. I verify the string is 
indeed in Wayland clipboard, I paste it in Firefox, or in the terminal (not Emacs).

Now I do `C-y`: this later string is not pasted, even though it should have been. I do `M-y` 
to see if I can find the string in the kill-ring: I can't find the string in the kill-ring.

What, instead, is the string at the top of Emacs kill-ring: the string "URL" (from the initial 
org-protocol action).

So Emacs has now stopped inserting strings from Wayland-clipboard into Emacs kill-ring.

No matter how hard I try.

The labor-intensive workaround:

Now what I do is copy a string inside Emacs using `C-w`.

Then, I verify if I can past it in Firefox: I can. It really is in Wayland clipboard.

Now I copy a string from Firefox into Emacs: it is not broken anymore, until the next time I 
use org-protocol, at which point it gets broken again.

And now it really is also present in Emacs kill-ring.

> save-interprogram-paste-before-kill:
>         Whether to save existing clipboard text into kill ring before
> replacing it. select-enable-primary:
>         Non-nil means cutting and pasting uses the primary selection.
> 
> Best,
> Ihor



[-- Attachment #2: Type: text/html, Size: 6764 bytes --]

Re: cut and paste not working after xdg-open "org-protocol://store-link?url=URL&title=TITLE"

[Ihor Radchenko]

chris <inkbottle007@gmail.com> writes:

> After doing `xdg-open "org-protocol://store-link?url=URL&title=TITLE"`.
> The string "URL" is pushed into Emacs kill-ring.
> But, this very string "URL", is not inserted into Wayland clipboard.

I am not using Wayland. However, if I just do (kill-new "test") in X and
my select-enable-primary is nil (default) - "test" will not go to my X
clipboard. It is the default behaviour of Emacs in X that has nothing to
do with Org mode.

What will happen if you try (kill-new "something") in your Emacs
(preferably, emacs -Q)? Will "something" be present in your Wayland
clipboard?

Best,
Ihor

Re: cut and paste not working after xdg-open "org-protocol://store-link?url=URL&title=TITLE"

[chris]

On Monday, 31 January 2022 02:14:34 CET Ihor Radchenko wrote:
> chris <inkbottle007@gmail.com> writes:
> > After doing `xdg-open "org-protocol://store-link?url=URL&title=TITLE"`.
> > The string "URL" is pushed into Emacs kill-ring.
> > But, this very string "URL", is not inserted into Wayland clipboard.
> 
> I am not using Wayland. However, if I just do (kill-new "test") in X and
> my select-enable-primary is nil (default) - "test" will not go to my X
> clipboard. It is the default behaviour of Emacs in X that has nothing to
> do with Org mode.
> 
> What will happen if you try (kill-new "something") in your Emacs
> (preferably, emacs -Q)? Will "something" be present in your Wayland
> clipboard?

emacs -Q, then `M-: (kill-new "something")`
Then `C-y` in `*scratch*`, string "something" is pasted.
Then go to terminal (Konsole, specifically), `C-S-v`, string "something" is 
pasted, too.

Also, I understand your point, but the fact that the copying is working or not 
working, in that direction, specifically, after using `xdg-open "org-
protocol://store-link?url=URL&title=TITLE"`, etc...
Is really a detail in what is hindering the workflow there. What is hindering 
the workflow is that the cut and past in the opposite direction, namely from 
the terminal to emacs, stops working from that point onward.
And that is really cumbersome.
And again, at that point the only workaround I've found to have the cut and 
past from terminal to emacs working again, is to perform one operation of 
copying from emacs to the terminal.
If ever I omit that workaround step, next time I'll copy something from the 
terminal to emacs, it will end up in pasting the string that has been 
initially inserted into the kill-ring by `xdg-open "org-protocol://store-link?
url=URL&title=TITLE"` possibly hours before, so to speak.

And no, even though `M-: (kill-new "something")` is putting "something" in 
both kill-ring and wayland-clipboard as stated above, `xdg-open "org-
protocol://store-link?url=URL&title=TITLE"`, is only putting "URL" in the 
kill-ring, or so I have observe to the best of my knowledge: and it is not the 
issue in my workflow, only an observation I've made.

> 
> Best,
> Ihor

Re: cut and paste not working after xdg-open "org-protocol://store-link?url=URL&title=TITLE"

[Ihor Radchenko]

chris <inkbottle007@gmail.com> writes:

>> What will happen if you try (kill-new "something") in your Emacs
>> (preferably, emacs -Q)? Will "something" be present in your Wayland
>> clipboard?
>
> emacs -Q, then `M-: (kill-new "something")`
> Then `C-y` in `*scratch*`, string "something" is pasted.
> Then go to terminal (Konsole, specifically), `C-S-v`, string "something" is 
> pasted, too.

Got it. What about emacsclient -e "(kill-new \"test123\")"?

> Also, I understand your point, but the fact that the copying is working or not 
> working, in that direction, specifically, after using `xdg-open "org-
> protocol://store-link?url=URL&title=TITLE"`, etc...
> Is really a detail in what is hindering the workflow there.

It seems that you don't (: To clarify, I am not trying to find a
workaround for you yet, but trying to figure out if what you observe is
a Emacs bug, an Org mode bug, or not bug at all.

Best,
Ihor

Re: cut and paste not working after xdg-open "org-protocol://store-link?url=URL&title=TITLE"

[chris]

[-- Attachment #1: Type: text/plain, Size: 1357 bytes --]

On Monday, 31 January 2022 04:28:06 CET Ihor Radchenko wrote:
> chris <inkbottle007@gmail.com> writes:
> >> What will happen if you try (kill-new "something") in your Emacs
> >> (preferably, emacs -Q)? Will "something" be present in your Wayland
> >> clipboard?
> > 
> > emacs -Q, then `M-: (kill-new "something")`
> > Then `C-y` in `*scratch*`, string "something" is pasted.
> > Then go to terminal (Konsole, specifically), `C-S-v`, string "something"
> > is
> > pasted, too.
> 
> Got it. What about emacsclient -e "(kill-new \"test123\")"?

`~/path-to-emacs/lib-src/emacsclient -e "(kill-new \"test123
\")"`

Emacs side, `C-y` => "test123"

Terminal side, `C-S-v` => no trace of the "test123" string.

(note that I don't have emacs system wide, only the emacs 29.0.50 build from source, so 
there can be no conflict between two emacs)


> > Also, I understand your point, but the fact that the copying is working or
> > not working, in that direction, specifically, after using `xdg-open "org-
> > protocol://store-link?url=URL&title=TITLE"`, etc...
> > Is really a detail in what is hindering the workflow there.
> 
> It seems that you don't (: To clarify, I am not trying to find a
> workaround for you yet, but trying to figure out if what you observe is
> a Emacs bug, an Org mode bug, or not bug at all.

Yeah, sorry about that.

> 
> Best,
> Ihor



[-- Attachment #2: Type: text/html, Size: 4050 bytes --]

Re: cut and paste not working after xdg-open "org-protocol://store-link?url=URL&title=TITLE"

[chris]

On Monday, 31 January 2022 04:43:34 CET chris wrote:
> On Monday, 31 January 2022 04:28:06 CET Ihor Radchenko wrote:
> > chris <inkbottle007@gmail.com> writes:
> > >> What will happen if you try (kill-new "something") in your Emacs
> > >> (preferably, emacs -Q)? Will "something" be present in your Wayland
> > >> clipboard?
> > > 
> > > emacs -Q, then `M-: (kill-new "something")`
> > > Then `C-y` in `*scratch*`, string "something" is pasted.
> > > Then go to terminal (Konsole, specifically), `C-S-v`, string "something"
> > > is
> > > pasted, too.
> > 
> > Got it. What about emacsclient -e "(kill-new \"test123\")"?
> 
> `~/path-to-emacs/lib-src/emacsclient -e "(kill-new \"test123
> \")"`
> 
> Emacs side, `C-y` => "test123"
> 
> Terminal side, `C-S-v` => no trace of the "test123" string.

My, I missed one pivotal point:
Right after that operation, I cannot cut and paste straight away from terminal 
to emacs.
If I copy and paste some string "test567" from terminal to Firefox or 
whatever, it is working fine, but `C-y` in emacs is still "test123".

> 
> (note that I don't have emacs system wide, only the emacs 29.0.50 build from
> source, so there can be no conflict between two emacs)
> 
> > > Also, I understand your point, but the fact that the copying is working
> > > or
> > > not working, in that direction, specifically, after using `xdg-open
> > > "org-
> > > protocol://store-link?url=URL&title=TITLE"`, etc...
> > > Is really a detail in what is hindering the workflow there.
> > 
> > It seems that you don't (: To clarify, I am not trying to find a
> > workaround for you yet, but trying to figure out if what you observe is
> > a Emacs bug, an Org mode bug, or not bug at all.
> 
> Yeah, sorry about that.
> 
> > Best,
> > Ihor

Re: cut and paste not working after xdg-open "org-protocol://store-link?url=URL&title=TITLE"

[chris]

On Monday, 31 January 2022 04:49:59 CET chris wrote:
> On Monday, 31 January 2022 04:43:34 CET chris wrote:
> > On Monday, 31 January 2022 04:28:06 CET Ihor Radchenko wrote:
> > > chris <inkbottle007@gmail.com> writes:
> > > >> What will happen if you try (kill-new "something") in your Emacs
> > > >> (preferably, emacs -Q)? Will "something" be present in your Wayland
> > > >> clipboard?
> > > > 
> > > > emacs -Q, then `M-: (kill-new "something")`
> > > > Then `C-y` in `*scratch*`, string "something" is pasted.
> > > > Then go to terminal (Konsole, specifically), `C-S-v`, string
> > > > "something"
> > > > is
> > > > pasted, too.
> > > 
> > > Got it. What about emacsclient -e "(kill-new \"test123\")"?
> > 
> > `~/path-to-emacs/lib-src/emacsclient -e "(kill-new \"test123
> > \")"`
> > 
> > Emacs side, `C-y` => "test123"
> > 
> > Terminal side, `C-S-v` => no trace of the "test123" string.
> 
> My, I missed one pivotal point:
> Right after that operation, I cannot cut and paste straight away from
> terminal to emacs.
> If I copy and paste some string "test567" from terminal to Firefox or
> whatever, it is working fine, but `C-y` in emacs is still "test123".
> 

Also, right now, emacs kill-ring is not very big, less than 10 items, so I can 
see all of them using `M-y`, and the most recent one, after several cut-and-
paste operations none of them emacs related, is still "test123".

And so now I do the converse operation and that works, and after that copying 
from terminal to emacs works again.

Bottom line, it seems org-mode independent.

> > (note that I don't have emacs system wide, only the emacs 29.0.50 build
> > from source, so there can be no conflict between two emacs)
> > 
> > > > Also, I understand your point, but the fact that the copying is
> > > > working
> > > > or
> > > > not working, in that direction, specifically, after using `xdg-open
> > > > "org-
> > > > protocol://store-link?url=URL&title=TITLE"`, etc...
> > > > Is really a detail in what is hindering the workflow there.
> > > 
> > > It seems that you don't (: To clarify, I am not trying to find a
> > > workaround for you yet, but trying to figure out if what you observe is
> > > a Emacs bug, an Org mode bug, or not bug at all.
> > 
> > Yeah, sorry about that.
> > 
> > > Best,
> > > Ihor

Re: cut and paste not working after xdg-open "org-protocol://store-link?url=URL&title=TITLE"

[Tim Cross]

chris <inkbottle007@gmail.com> writes:

> On Monday, 31 January 2022 04:49:59 CET chris wrote:
>> On Monday, 31 January 2022 04:43:34 CET chris wrote:
>> > On Monday, 31 January 2022 04:28:06 CET Ihor Radchenko wrote:
>> > > chris <inkbottle007@gmail.com> writes:
>> > > >> What will happen if you try (kill-new "something") in your Emacs
>> > > >> (preferably, emacs -Q)? Will "something" be present in your Wayland
>> > > >> clipboard?
>> > > > 
>> > > > emacs -Q, then `M-: (kill-new "something")`
>> > > > Then `C-y` in `*scratch*`, string "something" is pasted.
>> > > > Then go to terminal (Konsole, specifically), `C-S-v`, string
>> > > > "something"
>> > > > is
>> > > > pasted, too.
>> > > 
>> > > Got it. What about emacsclient -e "(kill-new \"test123\")"?
>> > 
>> > `~/path-to-emacs/lib-src/emacsclient -e "(kill-new \"test123
>> > \")"`
>> > 
>> > Emacs side, `C-y` => "test123"
>> > 
>> > Terminal side, `C-S-v` => no trace of the "test123" string.
>> 
>> My, I missed one pivotal point:
>> Right after that operation, I cannot cut and paste straight away from
>> terminal to emacs.
>> If I copy and paste some string "test567" from terminal to Firefox or
>> whatever, it is working fine, but `C-y` in emacs is still "test123".
>> 
>
> Also, right now, emacs kill-ring is not very big, less than 10 items, so I can 
> see all of them using `M-y`, and the most recent one, after several cut-and-
> paste operations none of them emacs related, is still "test123".
>
> And so now I do the converse operation and that works, and after that copying 
> from terminal to emacs works again.
>
> Bottom line, it seems org-mode independent.
>

This is most likely an Emacs 29 issue. The pgtk stuff has only very
recently been pulled into the mainline development tree and it is very
likely that little testing has been done on wayland using the pure gtk
build (and I'm assuming no wayland X window integration layer).

You probably need to log it as an Emacs bug. It might be worthwhile
asking on the emacs-devel list - it could be a known issue.

Re: cut and paste not working after xdg-open "org-protocol://store-link?url=URL&title=TITLE"

[Max Nikulin]

On 31/01/2022 08:14, Ihor Radchenko wrote:
> chris writes:
> 
> I am not using Wayland. However, if I just do (kill-new "test") in X and
> my select-enable-primary is nil (default) - "test" will not go to my X
> clipboard. It is the default behaviour of Emacs in X that has nothing to
> do with Org mode.

Ihor, please, do not add more confusion to this obscure issue. 
`select-enable-primary' controls PRIMARY selection, not CLIPBOARD. 
`select-enable-clipboard' is an independent variable.

Chris, did you tune clipboard manager in KDE? This kind of software may 
cause quite peculiar behavior...

So, do not confuse PRIMARY selection and CLIPBOARD. Unlike MS Windows, 
X11 has several selection (and legacy cut buffers). I do not know the 
full story, but it seems that wayland developers decided that it is more 
secure to have just clipboard, but they did not sustain pressure of 
users who really like that "hard to discover feature": just select some
text with mouse without additional hotkeys and paste it using middle click.

Ububntu-21.10 impish, gnome, wayland, Emacs-27.1. I am aware that KDE 
may have rather different implementation related to wayland protocol and 
something may change in Emacs since the released version. I just have VM 
with such configuration.

New session, empty selection and clipboard:
$ wl-paste --list-types
No selection
$ wl-paste --primary --list-types
No selection

Select a word in terminal using mouse:
$ wl-paste --primary --list-types
text/plain
text/plain;charset=utf-8
STRING
TEXT
COMPOUND_TEXT
UTF8_STRING
$ wl-paste --list-types
No selection

[Ctrl+Shift+V] to copy selection to clipboard
$ wl-paste --primary --list-types
text/plain
text/plain;charset=utf-8
STRING
TEXT
COMPOUND_TEXT
UTF8_STRING
$ wl-paste --list-types
text/plain
text/plain;charset=utf-8
STRING
TEXT
COMPOUND_TEXT
UTF8_STRING

Let's copy some text from Firefox and then select another text
but do not copy it:
$ wl-paste
Copy from Firefox
$ wl-paste --primary
Just select in Firefox

So paste and insert using middle click are not synchronized now.

Execute the following in Emacs:
(kill-new "kill-new from Emacs")

CLIPBOARD is changed, PRIMARY selection is not, it can be tuned in Emacs 
settings. I like the default ones.
$ wl-paste
kill-new from Emacs
$ wl-paste --primary
Just select in Firefox

Re: cut and paste not working after xdg-open "org-protocol://store-link?url=URL&title=TITLE"

[chris]

[-- Attachment #1: Type: text/plain, Size: 3084 bytes --]

On Monday, 31 January 2022 17:29:28 CET Max Nikulin wrote:
> On 31/01/2022 08:14, Ihor Radchenko wrote:
> > chris writes:
> > 
> > I am not using Wayland. However, if I just do (kill-new "test") in X and
> > my select-enable-primary is nil (default) - "test" will not go to my X
> > clipboard. It is the default behaviour of Emacs in X that has nothing to
> > do with Org mode.

This quote above is not from me (Chris), I think it's from Ihor, I just say that to try not to 
add to confusion ;)
I myself, am using Wayland.

> Ihor, please, do not add more confusion to this obscure issue.
> `select-enable-primary' controls PRIMARY selection, not CLIPBOARD.
> `select-enable-clipboard' is an independent variable.
> 
> Chris, did you tune clipboard manager in KDE? This kind of software may
> cause quite peculiar behavior...

So, on debian/sid/kde/wayland, I've clicked on "configure clipboard" in the default plasma 
panel:
I can see "ignore selection" is selected. I don't like "primary selection", I think it's messy.

> 
> So, do not confuse PRIMARY selection and CLIPBOARD. Unlike MS Windows,
> X11 has several selection (and legacy cut buffers). I do not know the
> full story, but it seems that wayland developers decided that it is more
> secure to have just clipboard, but they did not sustain pressure of
> users who really like that "hard to discover feature": just select some
> text with mouse without additional hotkeys and paste it using middle click.

Yes, you inadvertently select text, and inadvertently paste it: that's legacy for you.

Well, look at that: 
https://bugs.kde.org/show_bug.cgi?id=441668[1]
"Recently middle-click pasting got implemented for the Wayland platform. However, this 
feature could be regarded as an annoyance due to the risk of inadvertent pasting.", etc.

So "selection ignored by the clipboard" according to kwin/wayland seems to mean "user 
can't see it when they look in the clipboard"
But it's fully working all right and you just can't disable it.
Awesome.

So yeah, debian-sid-kde-plasma-wayland:
There is both "primary selection"  and "clipboard" and you just can't disable "primary 
selection".

At least according to the above kde bug report.

> 
> Ububntu-21.10 impish, gnome, wayland, Emacs-27.1. I am aware that KDE
> may have rather different implementation related to wayland protocol and
> something may change in Emacs since the released version. I just have VM
> with such configuration.
> 
> New session, empty selection and clipboard:
> $ wl-paste --list-types
> No selection
> $ wl-paste --primary --list-types
> No selection
> 
> Select a word in terminal using mouse:
> $ wl-paste --primary --list-types
> text/plain
> text/plain;charset=utf-8
> STRING
> TEXT
> COMPOUND_TEXT
> UTF8_STRING
> $ wl-paste --list-types
> No selection
> 
> [Ctrl+Shift+V] to copy selection to clipboard
> $ wl-paste --primary --list-types
> text/plain
> text/plain;charset=utf-8
> STRING
> TEXT
> COMPOUND_TEXT
> UTF8_STRING
> $ wl-paste --list-types
> text/plain
> text/plain;charset=utf-8
> STRING
> TEXT
> COMPOUND_TEXT
> UTF8_STRING

[-- Attachment #2: Type: text/html, Size: 14643 bytes --]

Re: cut and paste not working after xdg-open "org-protocol://store-link?url=URL&title=TITLE"

[chris]

(previous email has been truncated? resending)

On Monday, 31 January 2022 17:29:28 CET Max Nikulin wrote:
> On 31/01/2022 08:14, Ihor Radchenko wrote:
> > chris writes:
> > 
> > I am not using Wayland. However, if I just do (kill-new "test") in X and
> > my select-enable-primary is nil (default) - "test" will not go to my X
> > clipboard. It is the default behaviour of Emacs in X that has nothing to
> > do with Org mode.

This quote above is not from me (Chris), I think it's from Ihor, I just say 
that to try not to add to confusion ;)
I myself, am using Wayland.

> Ihor, please, do not add more confusion to this obscure issue.
> `select-enable-primary' controls PRIMARY selection, not CLIPBOARD.
> `select-enable-clipboard' is an independent variable.
> 
> Chris, did you tune clipboard manager in KDE? This kind of software may
> cause quite peculiar behavior...

So, on debian/sid/kde/wayland, I've clicked on "configure clipboard" in the 
default plasma panel:
I can see "ignore selection" is selected. I don't like "primary selection", I 
think it's messy.

> 
> So, do not confuse PRIMARY selection and CLIPBOARD. Unlike MS Windows,
> X11 has several selection (and legacy cut buffers). I do not know the
> full story, but it seems that wayland developers decided that it is more
> secure to have just clipboard, but they did not sustain pressure of
> users who really like that "hard to discover feature": just select some
> text with mouse without additional hotkeys and paste it using middle click.

Yes, you inadvertently select text, and inadvertently paste it: that's legacy 
for you.

Well, look at that: 
https://bugs.kde.org/show_bug.cgi?id=441668
"Recently middle-click pasting got implemented for the Wayland platform. 
However, this feature could be regarded as an annoyance due to the risk of 
inadvertent pasting.", etc.

So "selection ignored by the clipboard" according to kwin/wayland seems to 
mean "user can't see it when they look in the clipboard"
But it's fully working all right and you just can't disable it.
Awesome.

So yeah, debian-sid-kde-plasma-wayland:
There is both "primary selection"  and "clipboard" and you just can't disable 
"primary selection".

At least according to the above kde bug report.

> 
> Ububntu-21.10 impish, gnome, wayland, Emacs-27.1. I am aware that KDE
> may have rather different implementation related to wayland protocol and
> something may change in Emacs since the released version. I just have VM
> with such configuration.
> 
> New session, empty selection and clipboard:
> $ wl-paste --list-types
> No selection
> $ wl-paste --primary --list-types
> No selection
> 
> Select a word in terminal using mouse:
> $ wl-paste --primary --list-types
> text/plain
> text/plain;charset=utf-8
> STRING
> TEXT
> COMPOUND_TEXT
> UTF8_STRING
> $ wl-paste --list-types
> No selection
> 
> [Ctrl+Shift+V] to copy selection to clipboard
> $ wl-paste --primary --list-types
> text/plain
> text/plain;charset=utf-8
> STRING
> TEXT
> COMPOUND_TEXT
> UTF8_STRING
> $ wl-paste --list-types
> text/plain
> text/plain;charset=utf-8
> STRING
> TEXT
> COMPOUND_TEXT
> UTF8_STRING
> 
> Let's copy some text from Firefox and then select another text
> but do not copy it:
> $ wl-paste
> Copy from Firefox
> $ wl-paste --primary
> Just select in Firefox
> 
> So paste and insert using middle click are not synchronized now.
> 
> Execute the following in Emacs:
> (kill-new "kill-new from Emacs")

Okay, at this point, we have seen, from the kde bug above (https://
bugs.kde.org/show_bug.cgi?id=441668), that things are a little bit in a mess, 
right now.

So when I use `wl-paste`, `wl-paste --primary`, `wl-paste --list-types`, `wl-
paste --primary --list-types`, I've got results whose logic is following the 
logic of your examples, with "primary selection" and "clipboard" living their 
separated lives, and not being synchronized, etc.

But when I use `(kill-new "kill-new from Emacs")`, I've got results "way 
superior to yours".

On the one hand, if I do:
`~/path/emacsclient --create-frame --altern
ate-editor=""`
Then go to `*scratch*`
Then `(kill-new "kill-new from Emacs")`
Then `C-y` gives `kill-new from Emacs`, and,
$ wl-paste 
kill-new from Emacs 
$ wl-paste --primary 
(kill-new "kill-new from Emacs")

On the other hand, if I do `~/path/emacsclient -e "(kill-new \"test523
\")"`, I get:
$ wl-paste --primary; wl-paste 
emacsclient -e "(kill-new \"test523\")" 
emacsclient -e "(kill-new \"test523\")"
And if I go to the emacsclient actual frame that I've kept open from the 
example above, and do `C-y`, I get:
test523

So on my system, 
`emacsclient -e "(kill-new \"test523\")"`
And
`(kill-new "test523")` executed in a emacsclient frame, in `*scratch*`, with 
`C-j`.

They don't agree.

And when I do one version, then the other version, then the first version, and 
try `wl-paste`, very quickly I get a `wl-paste` command that doesn't return, 
and that I have to stop with "C-c in a terminal let's not get confused".

So I think that settles things on my side: it's a mess, let's burry it, forget 
about it.

> CLIPBOARD is changed, PRIMARY selection is not, it can be tuned in Emacs
> settings. I like the default ones.
> $ wl-paste
> kill-new from Emacs
> $ wl-paste --primary
> Just select in Firefox

Re: cut and paste not working after xdg-open "org-protocol://store-link?url=URL&title=TITLE"

[Max Nikulin]

On 01/02/2022 12:57, chris wrote:
> On Monday, 31 January 2022 17:29:28 CET Max Nikulin wrote:
>> On 31/01/2022 08:14, Ihor Radchenko wrote:
>>> chris writes:
>>>
>>> I am not using Wayland. However, if I just do (kill-new "test") in X and
>>> my select-enable-primary is nil (default) - "test" will not go to my X
>>> clipboard. It is the default behaviour of Emacs in X that has nothing to
>>> do with Org mode.
> 
> This quote above is not from me (Chris), I think it's from Ihor,

I agree that I forgot to remove "chris writes:" line since I did not put 
anything from your messages. However I believed it is clear enough that 
with such style your quotes would have one more ">" character at 
beginning of lines.

>> Chris, did you tune clipboard manager in KDE? This kind of software may
>> cause quite peculiar behavior...
> 
> So, on debian/sid/kde/wayland, I've clicked on "configure clipboard" in the
> default plasma panel:
> I can see "ignore selection" is selected. I don't like "primary selection", I
> think it's messy.

Does it mean that you did something in settings to get 
clipboard&selection behavior more close to your expectations? Since I 
have klipper disabled, I do not remember its defaults and effects of its 
settings.

> Well, look at that:
> https://bugs.kde.org/show_bug.cgi?id=441668
> "Recently middle-click pasting got implemented for the Wayland platform.
> However, this feature could be regarded as an annoyance due to the risk of
> inadvertent pasting.", etc.
> 
> So "selection ignored by the clipboard" according to kwin/wayland seems to
> mean "user can't see it when they look in the clipboard"
> But it's fully working all right and you just can't disable it.

Low quality touchpad that accidentally spits middle-click events should 
be a real pain. However I can not understand your phrase above.

> On the one hand, if I do:
> `~/path/emacsclient --create-frame --altern
> ate-editor=""`
> Then go to `*scratch*`
> Then `(kill-new "kill-new from Emacs")`
> Then `C-y` gives `kill-new from Emacs`, and,

C-y queries desktop clipboard or/and selection (depending on 
`select-enable-clipboard' and `select-enable-primary' values), so it may 
affect result of the following commands.

> $ wl-paste
> kill-new from Emacs
> $ wl-paste --primary
> (kill-new "kill-new from Emacs")

What is the source of '(kill-new "kill-new from Emacs")' text in PRIMARY 
selection? Did it survived since you selected it in the message to paste 
it to Emacs?

> So on my system,
> `emacsclient -e "(kill-new \"test523\")"`
> And
> `(kill-new "test523")` executed in a emacsclient frame, in `*scratch*`, with
> `C-j`.
> 
> They don't agree.

Does it happen when klipper is not running? I do not know if it is 
possible to enable logging of clipboard and selection events to shed 
some light which application push content to them. Maybe application can 
be obtained from some "type" present in "wl-paste --list-types" output 
(and with --primary).

Even
    emacsclient -e select-enable-primary
    emacsclient -e select-enable-clipboard
may clarify things a bit.

So either
- clipboard manager does some fancy stuff (e.g. to make clipboard 
content available after application quit or to copy text from selection 
to clipboard or vice versa) and emacs is confused by such actions
- or pgtk emacs builds have some clipboard problems on wayland.

Till behavior of emacs+wayland+clipboard manager is clarified it is hard 
to make conclusions related to org-protocol behavior.