From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id 4PsPHldN9mHCBwEAgWs5BA (envelope-from ) for ; Sun, 30 Jan 2022 09:33:27 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id SDKnGldN9mEmKQEAauVa8A (envelope-from ) for ; Sun, 30 Jan 2022 09:33:27 +0100 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 3158A9972 for ; Sun, 30 Jan 2022 09:33:27 +0100 (CET) Received: from localhost ([::1]:36536 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nE5eI-0007Rn-AE for larch@yhetil.org; Sun, 30 Jan 2022 03:33:26 -0500 Received: from eggs.gnu.org ([209.51.188.92]:46124) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nE5d7-0007RI-HO for emacs-orgmode@gnu.org; Sun, 30 Jan 2022 03:32:13 -0500 Received: from ciao.gmane.io ([116.202.254.214]:34380) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nE5d5-0006Bb-Qi for emacs-orgmode@gnu.org; Sun, 30 Jan 2022 03:32:13 -0500 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1nE5d2-0007ET-Qt for emacs-orgmode@gnu.org; Sun, 30 Jan 2022 09:32:08 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: emacs-orgmode@gnu.org 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 Message-ID: References: <1902025.jDVfpnRRgo@pluto> <3701125.3ICyicTkgz@pluto> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Content-Language: en-US In-Reply-To: <3701125.3ICyicTkgz@pluto> Received-SPF: pass client-ip=116.202.254.214; envelope-from=geo-emacs-orgmode@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: 28 X-Spam_score: 2.8 X-Spam_bar: ++ X-Spam_report: (2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FORGED_MUA_MOZILLA=2.309, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, NICE_REPLY_A=-0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1643531607; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=fM0iSmRy/OAav65+EN1FsrCKl2qvxpNc65F4d9sJq90=; b=BGd9Jb45uO61s/8W/eGSzVfxDY8gsdiLLHEsd3uQy0qZgZVY2GiGxfTeGw1LmhpEo8tCvY osiv9tpG7sFcnMvPqlvdfAYN4fpY0TPM5Foi878Ri5Evo5rUTuEmtcKrGpO0bLtg5UrWG0 KWKu5pKKRPEwHPASXQEoz2PnYveySjG/N9TwO1bmvAy4cPqGlcT1xL8h/VQ3ZrmngckvTn rPkF9E1Bf5yLV+rKJF/Mi3yeyZFzGNeBQEiyvXiSrFYzEJpTPp/5qf+7pRNLA/PFwCzovS FQSMM6OazcI/xs4iw6eZWVaMjbly7zObcgcHvG2XsG0MEAQIP1JYWxIq3DBSSA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1643531607; a=rsa-sha256; cv=none; b=dywIU+mD6DrKfkMgX2M0YcYyLgAaPjn8bCIs1KbJIgHsJjvxZ1yymcu+Sb4HgSj8PpXCOY /KCBbqOHgAq3pKXmzC8GX49HFB0ISZOV48gNUG81FUnGbkfs3ZB6KXlcJ6TGkr3q51gFHH RyLb7QoWf4oXdT1PRAj+ZljHJoJRU2zMyNfhRZh89Ul3t0qM5Q9uMlq2fUB4JoCLcbyEVu 4XjAiLLp/d73icpt3TofEackHECoVaNZFXH87Yf6rMKdz2OYvhxrgvYTf4HF8Ls2PGBelb Ah7k2wwzxbvzbxOTsI2FKSeGB+iWi4gSBiSGsjuVXRpPCmyXaoCh0H130HLl3A== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -2.53 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 3158A9972 X-Spam-Score: -2.53 X-Migadu-Scanner: scn1.migadu.com X-TUID: reCFNLKQOLl3 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 >>> >> 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.