From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Visuwesh Newsgroups: gmane.emacs.bugs Subject: bug#75116: [PATCH] Make 'yank-media' autoselect the best media type Date: Fri, 27 Dec 2024 14:28:53 +0530 Message-ID: <871pxtcxiq.fsf@gmail.com> References: <87o70yeiih.fsf@gmail.com> <86r05uxx4i.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25262"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: yantar92@posteo.net, pinmacs@cas.cat, rpluim@gmail.com, 75116@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Dec 27 10:00:15 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tR6Cc-0006Oh-Ay for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 27 Dec 2024 10:00:14 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tR6CT-0008LB-1D; Fri, 27 Dec 2024 04:00:05 -0500 Original-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 1tR6CR-0008L0-Cv for bug-gnu-emacs@gnu.org; Fri, 27 Dec 2024 04:00:03 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tR6CQ-0008JQ-VR for bug-gnu-emacs@gnu.org; Fri, 27 Dec 2024 04:00:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-Version:Date:References:In-Reply-To:From:To:Subject; bh=qLiJ0YNcoKETMt9BFb8drLgXofm/QQUHeqi/c00AiRY=; b=jUSYbfO2C9mgDlzKhzIFuNO1HQi+5QfXU2IXOHvdNJUVbXT85SikEHpo5ZLyX3DqK9Ld3ePC3UDGZ50zJtM3gE3F3pXYQ3FYM8ABb19trs/aUuFy0ZdL3dhUwVCmuE2WeWwyuir5OQ001l2ThHQvt4J4mXtdFkzj7gKxBFmSEwbvlS6GR8XC8muef9MeEJjthsm1gM0J0xMp2hbJJfXBNG3bXxNT29jd+yfm+MtL/Zn6bT6U3WL3t8OyakYuFtUL9NGStZioul4h+x5Anst7hZmSEL6tElK2cmsgc5SzuaOcYvxo7vE56/dgGTnUGQwmI4OruLlz/Vd8WDqaRfqvAQ==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tR6CQ-0004XM-Nn for bug-gnu-emacs@gnu.org; Fri, 27 Dec 2024 04:00:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Visuwesh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 27 Dec 2024 09:00:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 75116 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 75116-submit@debbugs.gnu.org id=B75116.173529000017405 (code B ref 75116); Fri, 27 Dec 2024 09:00:02 +0000 Original-Received: (at 75116) by debbugs.gnu.org; 27 Dec 2024 09:00:00 +0000 Original-Received: from localhost ([127.0.0.1]:44658 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tR6CO-0004We-1X for submit@debbugs.gnu.org; Fri, 27 Dec 2024 04:00:00 -0500 Original-Received: from mail-pl1-f193.google.com ([209.85.214.193]:48189) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tR6CL-0004WU-FX for 75116@debbugs.gnu.org; Fri, 27 Dec 2024 03:59:58 -0500 Original-Received: by mail-pl1-f193.google.com with SMTP id d9443c01a7336-216281bc30fso98904065ad.0 for <75116@debbugs.gnu.org>; Fri, 27 Dec 2024 00:59:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1735289936; x=1735894736; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=qLiJ0YNcoKETMt9BFb8drLgXofm/QQUHeqi/c00AiRY=; b=OoW2jQ9EJxEXAzTJg+HBnQmz4LepoxWNBzqat77gOKFGWqc7cYfO2aVY0wA5RcXgiv eWcv8IhbbdXUcMB8QUkmQ2XnHxgq1KL2558rZYcB80QhnetOGMXYGvNse2dIzK6uzuJk kB0mPIQ7yiG6pMaKu42/AivHHacgw9OLdLzCu4sTmhysXL2ohx5TGLfSRHv8kIFcYPX/ j+lr6CxzaqpUCbLfd/tlogw/VtRHvFQAB2SOzwRLFM0jxyWRzrbHy3NBHwm3yhPPfVzv goG2UofwGm5ybYjk1XXD3jA+aE59aV7Gbb6IbaxOfnOggJZ+UDMEiBzwMaSpYelmw77e NdXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735289936; x=1735894736; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=qLiJ0YNcoKETMt9BFb8drLgXofm/QQUHeqi/c00AiRY=; b=NIhxdsKTevYL+1DYYeCBEJ5YfovsZ5EMlLYP3wbUKIv03LliRZQT36KYqFzdXM6EHC cUsOvtejReWCpfM8sl/jKgN7r57nuqmgV1gcXDgX9HhYrif9mUSBJX8N706INcw3PXZ7 ZU5YHlrZezt2lYxwXvYms0m/yXDOKCCK2xN9nM99px1BU/lq9O9aGAaO9sQlFR4HSj6F 388eyKDF0mEuAeEhAOCNHV6hH3OHxSpDfhvR+ujo0DYWzSvrPjcR3HYmZUPDK17Pnc04 koEigqziwT0YBXUSLJuSazeF5IiZgX087TI92wq2UB44nD1uuILg9arjexRa4Ki2hplG qdlg== X-Gm-Message-State: AOJu0YzXirL4BkSqA2Wr5/60ylsn6Wy1Fd8lClVdOs6ZUnn6HRszVQH4 aNk+oR3G87EGfY7cqjv4gU+2+7YVtt68jc6U0b7Nej9gn2cIRP16 X-Gm-Gg: ASbGncvenmDdCq82anv6kbp+TneI6GM1O+4MNVDOc+kVZ3ghxrE2bPqLdc6gsSpMZUI URfOWXuZ4ZgTb3S3nTWJR4BBuGEvlzRncMLywuWbJrA+ghfN3VklYkhHtzigLo9v9KN5xYOKTbz 6TaW+KVp9UEcpVQk9jKSBmdqJClW2GDfxzm8ZW0YbrjbkaNT7IQji8X92yTelLxcrPsE+vaBMIx UGCoQu/Tu/LyhCv0zOcjM/IqW6pS/G/K2AGPbW+I0n43J5I5ylFSQ== X-Google-Smtp-Source: AGHT+IFINvOXrrOWDuxK5goa8ldB7TGff0V4BvHZqodIS8ucCmyNuU/0cCi14daWdWput2ts5qxEQw== X-Received: by 2002:a17:902:dace:b0:216:3732:ade3 with SMTP id d9443c01a7336-219e6f25fd1mr341116295ad.35.1735289936570; Fri, 27 Dec 2024 00:58:56 -0800 (PST) Original-Received: from localhost ([49.204.136.169]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-219dc962d5fsm131410355ad.38.2024.12.27.00.58.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 Dec 2024 00:58:56 -0800 (PST) In-Reply-To: <86r05uxx4i.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 26 Dec 2024 17:49:33 +0200") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:297818 Archived-At: [=E0=AE=B5=E0=AE=BF=E0=AE=AF=E0=AE=BE=E0=AE=B4=E0=AE=A9=E0=AF=8D =E0=AE=9F= =E0=AE=BF=E0=AE=9A=E0=AE=AE=E0=AF=8D=E0=AE=AA=E0=AE=B0=E0=AF=8D 26, 2024] E= li Zaretskii wrote: >> Cc: Ihor Radchenko , pinmacs@cas.cat, rpluim@gmail.= com, Eli Zaretskii >> From: Visuwesh >> Date: Thu, 26 Dec 2024 17:57:50 +0530 >>=20 >> This is a continuation of the long thread in emacs-devel: >> https://yhetil.org/emacs-devel/79fc91f3-c2c3-44db-9817-595808917f26@cas.= cat/ >>=20 >> This message provides a summary: >> https://yhetil.org/87r06cj2nd.fsf@gmail.com >>=20 >> Ihor wrote: >>=20 >> > The only comment is that leaving an option to return a list of types >> > rather than only a single type will make things more flexible. >>=20 >> And this is now done in the attached patch. > > Thanks. > >> Before I go about writing NEWS and updating the manual, what do you >> think about the attached instead? > > Some comments below. > >> I think the variable >> yank-media-preferred-types gives a more granular control for major-mode >> authors than (add-function (local 'yank-media-autoselect-function) ...) > > Maybe. But one of my comments is exactly about that: I don't quite > understand your intent for how major modes should use this variable > (since neither the doc string nor the comments spell that out). Would > you please explain your thoughts on that? I was thinking using a variable like yank-media-preferred-types would be easier to ensure that image/svg is tried _before_ image/png but not _before_ application/x-libreoffice-tsvc, etc. Maybe this is overengineering things. I do not hold a strong opinion here so if you think `yank-media-autoselect-function' is enough control for major-mode authors, that is enough. As for (add-function (local 'yank-media-autoselect-function) ...) scenario, taking Robert's example of preferring image/svg in some HTML documents, one could say (add-function :around (local 'yank-media-autoselect-function) (lambda (oldfun types) (if (memq 'image/svg types)=20 'image/svg (funcall oldfun types)))) >> +(defvar yank-media-preferred-types >> + `(;; Check first since LibreOffice also puts a PNG image in the >> + ;; clipboard when a table cell is copied. >> + application/x-libreoffice-tsvc >> + ;; Give PNG more priority. >> + image/png >> + image/jpeg >> + ;; These are files copied/cut to the clipboard from a file manager. >> + ,(lambda (mimetypes) >> + (seq-find (lambda (type) >> + (string-match-p "x-special/\\(gnome\\|KDE\\|mate\\)-fil= es" >> + (symbol-name type))) >> + mimetypes)) >> + ;; FIXME: We should have a way to handle text/rtf. >> + text/html) > > Not sure I understand the value you suggest. It seems to lack many > important types.=20=20 These are media types for which support for yank-media already exists: ./lisp/gnus/message.el:3180: (yank-media-handler "image/.*" #'message-= -yank-media-image-handler) ./lisp/org/org.el:20757: (yank-media-handler "image/.*" #'org--image= -yank-media-handler) ./lisp/org/org.el:20760: (yank-media-handler "x/special-\\(?:gnome\\= |KDE\\|mate\\)-files" ./lisp/textmodes/sgml-mode.el:2419: (yank-media-handler 'text/html #'h= tml-mode--html-yank-handler) ./lisp/textmodes/sgml-mode.el:2420: (yank-media-handler "image/.*" #'h= tml-mode--image-yank-handler) and org-mode's main branch recently gained support for application/x-libreoffice-tsvc. Personally, these are the only media types which I use/come across daily. Someone=E2=84=A2 needs to comment on other media types that are potentially useful. [ I have a patch for message.el to add support for x/special-gnome-files which I need to bring in sync with master and send soon=E2=84=A2. ] > Also, aren't at least some of the types system-dependent? Yes, definitely. x/special-gnome-files and application/x-libreoffice-tsvc are system- and software-dependent resp. This was one of my comments addressed in the message I posted to emacs-devel: The mimetype used for cut/copied files only works in Linux environments. If other platforms can present such file:// links in the clipboard and Emacs supports it, we would need to add it to the list too. If we want platform-agnostic types, I assume we need an abstraction layer on top that would present the clipboard data in a uniform manner. I do not have the means to work on this since I only use Linux systems. >> + "List of mime types in the order of preference. >> +Each element in the list should be a symbol to choose the mime type >> +denoted by it, or a function of one argument, the mime types available, >> +and should return the mime types to use.") > > If this is intended for major modes to override, we should say so in > the doc string. > >> +(defvar yank-media-autoselect-function #'yank-media-autoselect-function >> + "Function to auto select the best mime types when many are available. > ^^^^ > I suggest "more than one" there. "Many" could be misinterpreted to > exclude the case of just two possible types. Thanks, I was stuck on the phrasing here. >> + (setq pref-type (and (null noselect) >> + (funcall yank-media-autoselect-function >> + (mapcar #'car all-types)))) >> + (cond >> + ;; We have one preferred mime type so use it unconditionally. >> + ((and pref-type (symbolp pref-type)) >> + (funcall (cdr (assq pref-type all-types)) pref-type >> + (yank-media--get-selection pref-type))) >> + ;; The user chose to not autoselect and there's just a single type, >> + ;; just call the handler. >> + ((and (null pref-type) (length=3D all-types 1)) >> + (funcall (cdar all-types) (caar all-types) >> + (yank-media--get-selection (caar all-types)))) > > This goes against what the doc string says. And I think the doc > string describes a better behavior: if the user asked not to > auto-select, we shouldn't, even if there's just one type available. > We should instead ask the user whether to yank that type, because the > user could decide she doesn't want that type, even it it's the only > one. > > Also, I think we should show some message if > yank-media-autoselect-function returns nil. AFAIU, the code you > posted silently does nothing, which IMO is not the best UI. I want to ensure we are on the same page wrt UI here: User asks to autoselect: 1. autoselect-function (a-s-f) returns one media type: we yank it. 2. a-s-f returns multiple media types: we ask the user which one to yank. 3. a-s-f returns nil. We show a message and do what? If (length all-types) =3D 1, should we insert it no questions aske= d? If (length all-types) > 1, we ask as usual. =20=20=20=20=20=20=20=20=20 Or, should we proceed as if the user did not ask for autoselection? User asks not to autoselect: 4. (length all-types) =3D 1: We show the media type and ask if she wants to yank it. 5. (length all-types) > 1: We ask for the media type to yank. Excepting case (3), does the other cases sound good? >> I know that I have to update the Info node (info "(elisp) Yanking >> Media"). Does (info "(emacs) Clipboard") need any update too? > > IMO, yes. In fact, I think the user-facing part of the description of > yank-media should be moved to the Emacs user manual, the "Clipboard" > node. OK, yank-media is already documented in the Emacs user manual. We would need to talk about C-u and provide a description of auto-selection.