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

[Max Nikulin <manikulin@gmail.com>]

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.