From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:403:4789::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id 4NuGEk6WEWUXAAAA9RJhRA:P1 (envelope-from ) for ; Mon, 25 Sep 2023 16:16:46 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:4789::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id 4NuGEk6WEWUXAAAA9RJhRA (envelope-from ) for ; Mon, 25 Sep 2023 16:16:46 +0200 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 CBC1446B03 for ; Mon, 25 Sep 2023 16:16:45 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="FRi/NlNo"; 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"; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1695651406; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc: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:dkim-signature; bh=ZPjHO5wK6YyXehAvQAMexGSuNc8F+B4gZFAhkQ/fix4=; b=siWC8B04jN8S+g7N5/kc/gN2IIZLymao2ZwBsQrxyG/+FeDdsuqvbKWYP4O3GJ9IYgV5zR 1ItJRDZhDGUA+hzJIWzI2D+Cp2jM9X4rIJ/TPqjJ2tQXW3QxzZ7bB2HJvmzXLW+nCKKbmG GijL9iGnZyrzple8jIVyLtQb3eLs8W2vgBOYfAzUVvnLQpvdfNO6SkuddiWKIxR91fP1yf VAYB7PsEaX3qzGz2ZXuFghMUKU9d53WSl86TSUcBNK0Jw2/SMi4IC8P9h5snznljeFsE2p 0gCJrO1E46BtdIjg5HWOriiNoj6ubrLZbOSrBgl4qmIwAhiLBphRxZYMyoSBGg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1695651406; a=rsa-sha256; cv=none; b=Xixx+IMGIpMVHaWjTFaCrLhSiDXvcndxaFdCQyljpZUkSBMnzpX1jABiIZhBndp2QBZ+cU U3DhoijRMO5/EFmxDMe+0mEAJSrS+5PPEhDTL/2280NCy662djX+5bjcPuW4RmytPNsvQ8 Nz5KzxQ5cjY9nnjdDrT0t8A1ZxZnUgKjDExtVYTphytuHjcp5ySHKg0BrGxm/kyzi985MT qduDvcWPhXKxLrtgzRjfhDh6FeiPqEYxvYR1MWwVH1vjnwMsQ0LoUOc3rEO6Qd1+o6L2zH 6CfhNIBXe1OLUSuIAgiLXpt/ujqxTo5xoiEr/FpEpqvV58VSu/LxNendwfMJOA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="FRi/NlNo"; 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"; dmarc=pass (policy=none) header.from=gmail.com Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qkmNI-0006Mj-CE; Mon, 25 Sep 2023 10:15:48 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qkmNH-0006MX-DV for emacs-orgmode@gnu.org; Mon, 25 Sep 2023 10:15:47 -0400 Received: from mail-pj1-x1044.google.com ([2607:f8b0:4864:20::1044]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qkmN9-0002Fj-Ky for emacs-orgmode@gnu.org; Mon, 25 Sep 2023 10:15:42 -0400 Received: by mail-pj1-x1044.google.com with SMTP id 98e67ed59e1d1-2776fa0fac2so538948a91.0 for ; Mon, 25 Sep 2023 07:15:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695651338; x=1696256138; darn=gnu.org; h=content-transfer-encoding:mime-version:message-id:date:user-agent :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=ZPjHO5wK6YyXehAvQAMexGSuNc8F+B4gZFAhkQ/fix4=; b=FRi/NlNoIzDciARLHJqyAGmBJh1fOleWO1eItCIJCJoLC7saUxoon2oLjG+k2/vkgE P2Weyj/bi5DjqlgVhPweXtOZ+Nd3+c3W6pr4IkDtkAsWD0lndlTAB6qEmsVUTQ3/3Ahz W/ezdUVY+uo8s+kQsxRygkoW5GFlZdG+xFegwI5oFKW28K1zcgeTD4SGdkZbjQqfmFvP VCjREAu/Kxk9+1Jcxx6c6j3bhOUCe9MTCLSiUmpFku9N5+1m/WtQ2TrEgbjzhQ7tta30 JlFJgnJ+3t8wHpOmgpveVsT764bZrYCid1xCV9b68wdcAK8hA3D5XVzNLI3OFsLPucth +YKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695651338; x=1696256138; h=content-transfer-encoding:mime-version:message-id:date:user-agent :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=ZPjHO5wK6YyXehAvQAMexGSuNc8F+B4gZFAhkQ/fix4=; b=nReUoRy6F5+B91UGjn+IiRgcxi+Z0r+gxETVvlpc7/Z52t6Xz8VKpeAGwQlRF9cd1h eiVx0VIFIwvUhUTuh4ebZaE0rnjr9N4lt4k9v3C48TwQn8Z3sg6u0B8i5wnqYRKZqsnZ UkCaDEOoF9q6g+aall0tHzT5VWFY2l8KwXp8O+m2i8mwOWo3RGnp785/ovH1Rh5TnVcq yCEqIf+VYb/tuwWbjUUZ6xWxrizZiCxDFQhe0gw10s54zij0IDxlto3IVnvfZEeZNNpp ONmeIZZgPTp0PWWKvAH4gtpvUdd28xNN6F0r/4zLzOLTGj+KU8mpImAsSn7IdtgObAIT TcEw== X-Gm-Message-State: AOJu0YydJOT8Hco4Yy4wPnow/9cU4w4AWOnw8T8gEa99ZGTDS34ZIhg8 G50HD0fup3nFVUMHqiZn7V8= X-Google-Smtp-Source: AGHT+IH+mRzZxMKlaedUMmttrGybKinqj2w6ASixVPCcL3gKVWGreswXuXhwT25wbV28ovckKKVvGQ== X-Received: by 2002:a17:90a:4142:b0:274:77b7:660 with SMTP id m2-20020a17090a414200b0027477b70660mr9458925pjg.24.1695651337789; Mon, 25 Sep 2023 07:15:37 -0700 (PDT) Received: from localhost ([118.185.152.162]) by smtp.gmail.com with ESMTPSA id y14-20020a17090a134e00b0026d4100e0e8sm7945803pjf.10.2023.09.25.07.15.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 Sep 2023 07:15:37 -0700 (PDT) From: Visuwesh To: Max Nikulin Cc: emacs-orgmode@gnu.org Subject: Re: [BUG] [PATCH] Add yank-media and DND handler [9.6.7 (9.6.7-g6eb773 @ /home/viz/lib/emacs/straight/build/org/)] In-Reply-To: (Max Nikulin's message of "Sun, 24 Sep 2023 21:58:37 +0700") References: <87jzsintv0.fsf@gmail.com> <87lecx2nff.fsf@localhost> User-Agent: Gnus/5.13 (Gnus v5.13) Date: Mon, 25 Sep 2023 19:45:33 +0530 Message-ID: <87y1gul4oq.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2607:f8b0:4864:20::1044; envelope-from=visuweshm@gmail.com; helo=mail-pj1-x1044.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham 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-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN X-Spam-Score: -8.10 X-Migadu-Spam-Score: -8.10 X-Migadu-Scanner: mx1.migadu.com X-Migadu-Queue-Id: CBC1446B03 X-TUID: xIKPcBlzIDWw [ Please keep me in the CC as I don't follow the list. ] [=E0=AE=9E=E0=AE=BE=E0=AE=AF=E0=AE=BF=E0=AE=B1=E0=AF=81 =E0=AE=9A=E0=AF=86= =E0=AE=AA=E0=AF=8D=E0=AE=9F=E0=AE=AE=E0=AF=8D=E0=AE=AA=E0=AE=B0=E0=AF=8D 24= , 2023] Max Nikulin wrote: > On 23/09/2023 17:28, Ihor Radchenko wrote: >> Visuwesh writes: >>=20 >>> + (let* ((ext (symbol-name (mailcap-mime-type-to-extension mimetype))) >>> + (iname (read-string "Insert filename for image: ")) >> It would be nice if we auto-generate the file name here by >> default. It >> is what I would expect from yanking an image at least. > > Certainly it would be great to provide some default value allowing > user to override it. However it may be not so trivial. Clipboard > content may be just copy region from some graphics editor or a > screenshot tool, so not associated with a file yet. In X11 xprop may > be used to get clipboard owner application and its title. Wayland may > be less permissive. > > I have tried to copy an image in Firefox. There is a chance to find > file name (it may be image.php?id=3D1324 though) in text/html clipboard > content, but it requires parsing of HTML > > xclip -selection clipboard -o -t text/html I would rather not go down this rabbit hole since there is no way to cover all the possible cases. [=E0=AE=9E=E0=AE=BE=E0=AE=AF=E0=AE=BF=E0=AE=B1=E0=AF=81 =E0=AE=9A=E0=AF=86= =E0=AE=AA=E0=AF=8D=E0=AE=9F=E0=AE=AE=E0=AF=8D=E0=AE=AA=E0=AE=B0=E0=AF=8D 24= , 2023] Max Nikulin wrote: > On 22/09/2023 21:52, Visuwesh wrote: >> Attached patch adds yank-media and DND handler to attach files in the >> clipboard and dropped onto an Emacs frame respectively. > > Please, use `make-temp-file' to create files in the temporary > directory that may be world writable. Predictable file names there are > undesired from security point of view. What harm does it cause? > Other notes are no more than opinion. I may easily miss something and > verbose reply may be wasting of time. Do not hesitate to ask more > details if you do not agree. > > At first, I expected more common with the following project > https://github.com/abo-abo/org-download/ > however even the approach to fetch images from clipboard is different. I have never used that package, this is what I wrote in a discussion with Ihor in the Matrix room which we iteratively improved. It was mostly written with my workflow in mind. Without knowledge of how others work, I cannot improve the implementation. I also don't understand what the linked package from the Commentary section (which is why I never used it). >> +++ b/lisp/org.el > > I am in doubts if the following code is more suitable for org.el or > for org-attach.el I have the same doubts. >> @@ -20254,6 +20257,146 @@ it has a `diary' type." >> (org-format-timestamp timestamp fmt t)) >> (org-format-timestamp timestamp fmt (eq boundary 'end))))))) >> +;;; Yank media handler and DND >> +(defun org-setup-yank-dnd-handlers () >> + "Setup the `yank-media' and DND handlers for buffer." >> + (setq-local dnd-protocol-alist >> + (cons '("^file:///" . org--dnd-local-file-handler) >> + dnd-protocol-alist)) >> + (yank-media-handler "image/.*" #'org--image-yank-media-handler) >> + ;; Looks like different DEs go for different handler names, >> + ;; https://larsee.com/blog/2019/05/clipboard-files/. >> + (yank-media-handler "x/special-\\(?:gnome\|KDE\|mate\\)-files" >> + #'org--copied-files-yank-media-handler)) >> + >> +(defcustom org-media-image-save-type 'attach > > Could it be extended to any mime type? If so I would avoid "image" in > its name. `org-yank-media-save-dir'? It should be easy enough to do it but do we want to go there? >> + "Method to save images yanked from clipboard and dropped to Emacs. >> +It can be the symbol `attach' to add it as an attachment, or a >> +directory name to copy/cut the image to that directory." >> + :group 'org >> + :package-version '(Org . "9.7") >> + :type '(choice (const :tag "Add it as attachment" attach) >> + (directory :tag "Save it in directory")) >> + :safe (lambda (x) (or (stringp x) (eq x 'attach)))) > > Unsure if every directory may be considered as safe (e.g. ~/.ssh/) Is there a reliable way to know which directory is "safe"? If not, then let the users shoot themselves in the foot. >> + >> +(declare-function org-attach-attach "org-attach" (file &optional visit-= dir method)) >> + >> +(defun org--image-yank-media-handler (mimetype data) >> + "Save image DATA of mime-type MIMETYPE and insert link at point. >> +It is saved as per `org-media-image-save-type'. The name for the >> +image is prompted and the extension is automatically added to the >> +end." >> + (let* ((ext (symbol-name (mailcap-mime-type-to-extension mimetype))) >> + (iname (read-string "Insert filename for image: ")) > > Unless 'attach is used, `read-file-name' would allow saving to > arbitrary directory with path completion. Sorry, I don't understand what you mean here. I am not really familiar with attachment facilities of org-mode. >> + (filename (file-name-with-extension iname ext)) >> + (absname (expand-file-name >> + filename >> + (if (eq org-media-image-save-type 'attach) >> + temporary-file-directory > > `make-temp-file' should be used instead of `temporary-file-directory', > however it requires changes in code around. > >> + org-media-image-save-type))) >> + link) >> + (when (and (not (eq org-media-image-save-type 'attach)) >> + (not (file-directory-p org-media-image-save-type))) >> + (make-directory org-media-image-save-type t)) >> + (with-temp-file absname >> + (insert data)) >> + (if (null (eq org-media-image-save-type 'attach)) >> + (setq link (org-link-make-string >> + (concat "file:" (file-relative-name absname)) >> + filename)) > > Is there a chance to request for link description? Unsure if > `org-insert-link' may be easily reused. This would include too many prompts and make the whole process annoying again. >> [...] >> +(defcustom org-dnd-default-attach-method nil >> + "Default attach method to use when DND action is unspecified. >> +This attach method is used when the DND action is `private'. >> +This is also used when `org-media-image-save-type' is nil. >> +When nil, use `org-attach-method'." >> + :group 'org >> + :package-version '(Org . "9.7") >> + :type '(choice (const :tag "Default attach method" nil) >> + (const :tag "Copy" cp) >> + (const :tag "Move" mv) >> + (const :tag "Hard link" ln) >> + (const :tag "Symbol link" lns))) > > Labels in the menu below are a bit different. "Symbolic"? Okay, will make them both follow what org-attach uses. >> + >> +(declare-function mailcap-file-name-to-mime-type "mailcap" (file-name)) >> +(defvar org-attach-method) >> + >> +(defun org--dnd-local-file-handler (url action) >> + "Attach filename given by URL using method pertaining to ACTION. >> +If ACTION is `move', use `mv' attach method. >> +If `copy', use `cp' attach method. >> +If `ask', ask the user. >> +If `private', use the method denoted in `vz/org-dnd-default-attach-acti= on'. > > "vz/" likely should be dropped Yes, thanks for the catch. >> +The action `private' is always returned." >> + (require 'mailcap) >> + (let* ((filename (dnd-get-local-file-name url)) >> + (mimetype (mailcap-file-name-to-mime-type filename)) >> + (separatep (and (string-prefix-p "image/" mimetype) >> + (not (eq 'attach org-media-image-save-type)))) >> + (method (pcase action >> + ('copy 'cp) >> + ('move 'mv) >> + ('ask (caddr (read-multiple-choice > > `org-mks' has some issues, but it is the current way to present a kind > of menu in Org. Okay. >> + "Attach using method" >> + '((?c "cp" cp) >> + (?m "mv" mv) >> + (?l "ln hard link" ln) > > "ln" in the label perhaps should be dropped. I added ln to make the first letter bolded in rmc prompt, but with org-mks this shouldn't be necessary anymore. > Should it be hidden if stat reports different file systems for source > and target or fallback to copy is implicitly used? It should be handled appropriately by Emacs already. See (info "(emacs) Copying and Naming"). I also don't find org-attach doing anything special. >> + (?s "symbolic link" lns))))) >> + ('private (or org-dnd-default-attach-method >> + org-attach-method))))) >> + (if separatep >> + (funcall >> + (pcase method >> + ('cp #'copy-file) >> + ('mv #'rename-file) >> + ('ln #'add-name-to-file) >> + ('lns #'make-symbolic-link)) >> + filename >> + (expand-file-name (file-name-nondirectory filename) >> + org-media-image-save-type)) >> + (org-attach-attach filename nil method)) >> + (insert >> + (org-link-make-string >> + (concat (if separatep > > I would consider swapping of `concat' and `if' for the sake of readabilit= y. That can be done. >> + "file:" >> + "attachment:") >> + (if separatep >> + (expand-file-name (file-name-nondirectory filename) >> + org-media-image-save-type) >> + (file-name-nondirectory filename))) >> + (file-name-nondirectory filename)) >> + "\n") >> + 'private)) >> + >> ;;; Other stuff >> (defvar reftex-docstruct-symbol) >> --=20 > > I do not know if it can be easily implemented, but it may be useful to > control attachment/generic directory at the moment when a particular > image is yanked/dropped instead of purely relying on predefined user > option. Sorry, I don't understand what you mean here. Note that my usage of attachments is sparse. "Particular image" is hard to determine since the only reliable data at hand is its mimetype.