[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: cut and paste not working after xdg-open "org-protocol://store-link?
From: |
Max Nikulin |
Subject: |
Re: cut and paste not working after xdg-open "org-protocol://store-link?url=URL&title=TITLE" |
Date: |
Sun, 30 Jan 2022 15:31:59 +0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 |
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", (continued)
- Re: cut and paste not working after xdg-open "org-protocol://store-link?url=URL&title=TITLE", Ihor Radchenko, 2022/01/29
- Re: cut and paste not working after xdg-open "org-protocol://store-link?url=URL&title=TITLE", chris, 2022/01/30
- Re: cut and paste not working after xdg-open "org-protocol://store-link?url=URL&title=TITLE", Ihor Radchenko, 2022/01/30
- Re: cut and paste not working after xdg-open "org-protocol://store-link?url=URL&title=TITLE", chris, 2022/01/30
- Re: cut and paste not working after xdg-open "org-protocol://store-link?url=URL&title=TITLE", Ihor Radchenko, 2022/01/30
- Re: cut and paste not working after xdg-open "org-protocol://store-link?url=URL&title=TITLE", chris, 2022/01/30
- Re: cut and paste not working after xdg-open "org-protocol://store-link?url=URL&title=TITLE", chris, 2022/01/30
- Re: cut and paste not working after xdg-open "org-protocol://store-link?url=URL&title=TITLE", chris, 2022/01/30
- Re: cut and paste not working after xdg-open "org-protocol://store-link?url=URL&title=TITLE", Tim Cross, 2022/01/31
- Re: cut and paste not working after xdg-open "org-protocol://store-link?url=URL&title=TITLE", Max Nikulin, 2022/01/31
- Re: cut and paste not working after xdg-open "org-protocol://store-link?url=URL&title=TITLE",
Max Nikulin <=