From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#75116: [PATCH] Make 'yank-media' autoselect the best media type Date: Sat, 28 Dec 2024 14:24:04 +0200 Message-ID: <86r05sro63.fsf@gnu.org> References: <87o70yeiih.fsf@gmail.com> <86r05uxx4i.fsf@gnu.org> <871pxtcxiq.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1399"; mail-complaints-to="usenet@ciao.gmane.io" Cc: yantar92@posteo.net, pinmacs@cas.cat, rpluim@gmail.com, 75116@debbugs.gnu.org To: Visuwesh Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Dec 28 13:25:06 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 1tRVsQ-0000Cm-7E for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 28 Dec 2024 13:25:06 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tRVsN-0003Cs-Vt; Sat, 28 Dec 2024 07:25:04 -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 1tRVsN-0003Ck-6X for bug-gnu-emacs@gnu.org; Sat, 28 Dec 2024 07:25: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 1tRVsM-0005Q3-Q4 for bug-gnu-emacs@gnu.org; Sat, 28 Dec 2024 07:25:02 -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:References:In-Reply-To:From:Date:To:Subject; bh=iuXIs9PWnUwOZSH89pwanEZ5cAeFRLaG0Rn204glKhg=; b=WOyBGV2nsQ/12utW37Mdkzfl05Pylo8Ti2BMmspYfcgv+46uDP3bta8KVeDOThtY6lhi+UPCI/XQksxC463PyP5DYsVS72C4AXVHMhgdhlSW/ZySZ3/GhtI/yVEllq0ItI+c+84qeGK6ihmhQrv7cO9W54bBhEhSiW+2m4bx9gpNu00/Vz+53J6gzTGAMCdFun1aUDbkpgqAlAWmdlm4cUZWDN86UyNqwaxJr1dsiQNEHB0hsm8hDNUMZO9yqxCatyYT7ww7BAd7nqEIqYOIA6OeL5TlVhJU/xTbVmNTCPlSo7QP6mo2eHBNIuzipdYqVKwncBn0EAgXD91hU0H4OQ==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tRVsM-00025j-KG for bug-gnu-emacs@gnu.org; Sat, 28 Dec 2024 07:25:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 28 Dec 2024 12:25: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.17353886557966 (code B ref 75116); Sat, 28 Dec 2024 12:25:02 +0000 Original-Received: (at 75116) by debbugs.gnu.org; 28 Dec 2024 12:24:15 +0000 Original-Received: from localhost ([127.0.0.1]:49656 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tRVra-00024P-Lf for submit@debbugs.gnu.org; Sat, 28 Dec 2024 07:24:15 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:53286) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tRVrY-000248-Fj for 75116@debbugs.gnu.org; Sat, 28 Dec 2024 07:24:13 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tRVrS-0005FS-UC; Sat, 28 Dec 2024 07:24:07 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=iuXIs9PWnUwOZSH89pwanEZ5cAeFRLaG0Rn204glKhg=; b=GDbgVB5nvyOlZZpqGfxr ze6cyADoIevYWvEV4baX8UkzKGTaevWsz/xJjaadIYZ3Q3yG1ZJ+p3wceVMvcIJv5slwfIk6tYuPw nahjmRmzp7Mxu9b3U6xR/cVz1Gc4SLVd4coaqBnPcsVLhggvU60Nkdm1/BJX28bbsV+l57Z7Uwtov seo69B6mUxDIafrcF0qVnBoBerEJpneQeqkmTcU+f1ddky2Nm9Sok3JE8u3wKhjPfeWjaizgvyV15 ia8mHywNaRyT+tW3nx2S5tybWYdWBOGoVC//s2MxCi/WRxsD0fWwyEoOP7qqC5Ll3wrvMlr3/B8Ko iR+UV/qy0SKKAw==; In-Reply-To: <871pxtcxiq.fsf@gmail.com> (message from Visuwesh on Fri, 27 Dec 2024 14:28:53 +0530) 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:297895 Archived-At: > From: Visuwesh > Cc: 75116@debbugs.gnu.org, yantar92@posteo.net, pinmacs@cas.cat, > rpluim@gmail.com > Date: Fri, 27 Dec 2024 14:28:53 +0530 > > [வியாழன் டிசம்பர் 26, 2024] Eli Zaretskii wrote: > >> 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. If we intend for major modes to bind this variable, we should say so in the doc string, IMO. > >> +(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\\)-files" > >> + (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. > > These are media types for which support for yank-media already exists: I thought we should have here as many media types as possible, regardless of their support, because this variable expresses the relative priorities of the types. Major modes which add handlers should not need to also modify the value of this variable unnecessarily, no? > > 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. I just thought about having the value depend on the platform. > >> + (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= 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. Yes. > 2. a-s-f returns multiple media types: we ask the user which one > to yank. No, we use the first one. > 3. a-s-f returns nil. We show a message and do what? We show a message and do nothing. > User asks not to autoselect: > 4. (length all-types) = 1: We show the media type and ask if she > wants to yank it. Yes. > 5. (length all-types) > 1: We ask for the media type to yank. Yes. > Excepting case (3), does the other cases sound good? See above regarding my opinions.