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.devel Subject: Re: yank-media: allow users to limit image types that can be inserted Date: Tue, 29 Oct 2024 16:59:34 +0530 Message-ID: <87iktb171d.fsf@gmail.com> References: <79fc91f3-c2c3-44db-9817-595808917f26@cas.cat> <86ed5ahb08.fsf@gnu.org> <87zfnywki8.fsf@gmail.com> <86setqfnmq.fsf@gnu.org> <87frpqflv4.fsf@gmail.com> <86ikumfjri.fsf@gnu.org> <877cb2fj0c.fsf@gmail.com> <86cykufhw7.fsf@gnu.org> <3a015d0f-549a-401f-be1c-651c9dbd5d9a@cas.cat> <8634lqfcaf.fsf@gnu.org> <87ikulwsd6.fsf@gmail.com> <86o74ddzxp.fsf@gnu.org> <87msiqvkph.fsf@localhost> <86ed42bs03.fsf@gnu.org> <874j4yot7x.fsf@localhost> <861q01c3h9.fsf@gnu.org> <87wmht3n17.fsf@gmail.com> <86v7xdamck.fsf@gnu.org> <87sesh37ya.fsf@gmail.com> <86iktd8o9h.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8405"; 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, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Oct 29 12:30:55 2024 Return-path: Envelope-to: ged-emacs-devel@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 1t5kR5-00021r-4z for ged-emacs-devel@m.gmane-mx.org; Tue, 29 Oct 2024 12:30:55 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t5kQ7-0007Az-8Z; Tue, 29 Oct 2024 07:29:55 -0400 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 1t5kPw-0007A1-Uy for emacs-devel@gnu.org; Tue, 29 Oct 2024 07:29:45 -0400 Original-Received: from mail-pl1-x641.google.com ([2607:f8b0:4864:20::641]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1t5kPu-0002nW-RX; Tue, 29 Oct 2024 07:29:44 -0400 Original-Received: by mail-pl1-x641.google.com with SMTP id d9443c01a7336-20cdda5cfb6so50639145ad.3; Tue, 29 Oct 2024 04:29:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1730201380; x=1730806180; darn=gnu.org; h=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=T3KriZvm4V4Hukm9yL5W/n/27UEvq90CgABD3Ybr2v4=; b=byg2h8w36AWBXJhjheSolSuOHJrVS8lXhDmM/2YwFNohruQ+Ykz4oSirN4x8MQlSwO AfkFhbXZ8fowd9XpkbnloXq+fhUNcYPeecfWFGK0LpwIlpp7qIf5DhjcHOUp07jpB18W Ek+Xlg7MaqliYYn6/adAF9wVWRMZOsCdgdhyYJqKOVtfRqEfHXaMlfSy2ang/wuXHdql MkZQ4c2vAqxs+vus8qGQDrtDOFJ0zS3EXbbCK4UK7xuTl/0aHk83JdMLDzmR/qmQOHP3 fyPkrph+7D4zCfIisU0pttkCCVTu901KcHTFXalwArFcFSo1lZ9OFYyQho4/OihVB11z kKxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730201380; x=1730806180; h=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=T3KriZvm4V4Hukm9yL5W/n/27UEvq90CgABD3Ybr2v4=; b=tINWtL1JDullGwEak7EbJjzIDfsF5pDA2npTI+Tucfc3tE7xQrnTGjffRdZfmhEOgK o32IAuRMgMIugFunShQzRtoA67m97sNbmXSdsd1V+RteDpV7tjL8+kHB7P82p1R3oqUB W0qgTvtCH29AVGi/P1QrOmQexhsCVvcn7nk+62ie8Vt/PKllb/27hmnRq0/HsWNTb6uD ZAY4h28gp5wgUROUXD6ELrdUtYmTFya24B8wUorr94xcTeszxloCvgH5BXwaNhe8WSfo PqMvCm304qlmFcgVEX4zWr9pbgvR0NZH+I6W+jIW2mrJ0MY3kHIgfMLw5QrPB6/qcFS9 y2gw== X-Forwarded-Encrypted: i=1; AJvYcCUEVCMGBkAE30gpBoLwd6ob/h1/W7CBnwdRPYoaE/utz+xCcocG8L3ELRMNbrbMQhLQVtbhnLwTCCoNUQ==@gnu.org X-Gm-Message-State: AOJu0YxYFaSRv0p8r5OGpkICD7mbHq+TE/C4mtoFt9VZj2N/vOaM4D+r D6mDbXKz+lKe+Umyk/9qFF6yAbvNJxGy8hcNc37DpqRwfguIVPML0WagLRbH X-Google-Smtp-Source: AGHT+IFWHAVTYF+BEjd5uKzoBfrb1v0Zuvlk17WPkXUDuurJtATKEaEwPCJqDEZ0KQr6lVGu+7FDRg== X-Received: by 2002:a17:902:e810:b0:20c:e8df:251a with SMTP id d9443c01a7336-210c6ce0f99mr177876195ad.45.1730201379574; Tue, 29 Oct 2024 04:29:39 -0700 (PDT) Original-Received: from localhost ([115.240.90.130]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-210bc051316sm64530535ad.269.2024.10.29.04.29.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 29 Oct 2024 04:29:38 -0700 (PDT) In-Reply-To: <86iktd8o9h.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 27 Oct 2024 19:11:06 +0200") Received-SPF: pass client-ip=2607:f8b0:4864:20::641; envelope-from=visuweshm@gmail.com; helo=mail-pl1-x641.google.com X-Spam_score_int: -10 X-Spam_score: -1.1 X-Spam_bar: - X-Spam_report: (-1.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, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:324906 Archived-At: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable [=E0=AE=9E=E0=AE=BE=E0=AE=AF=E0=AE=BF=E0=AE=B1=E0=AF=81 =E0=AE=85=E0=AE=95= =E0=AF=8D=E0=AE=9F=E0=AF=8B=E0=AE=AA=E0=AE=B0=E0=AF=8D 27, 2024] Eli Zarets= kii wrote: >> From: Visuwesh >> Cc: yantar92@posteo.net, pinmacs@cas.cat, rpluim@gmail.com, >> emacs-devel@gnu.org >> Date: Sun, 27 Oct 2024 20:32:21 +0530 >>=20 >> [=E0=AE=9E=E0=AE=BE=E0=AE=AF=E0=AE=BF=E0=AE=B1=E0=AF=81 =E0=AE=85=E0=AE= =95=E0=AF=8D=E0=AE=9F=E0=AF=8B=E0=AE=AA=E0=AE=B0=E0=AF=8D 27, 2024] Eli Zar= etskii wrote: >>=20 >> >> > Examine the available TARGETS, then bind >> >> > yank-media--registered-handlers to the appropriate value when invok= ing >> >> > yank-media. >> >>=20 >> >> Would that not defeat the point of yank-media, which is to present a >> >> simple, common interface to the clipboard data to major-mode authors? >> > >> > Which part of the above would "defeat the point of yank-media", and >> > why? >>=20 >> yank-media presents a uniform interface to clipboard data across >> platforms, in principle. This implies that there is no need to know the >> ugly details of how the clipboard data is to be fetched, which data >> types are available and which of them are bogus, etc. > > My suggestion does not require any need to know those ugly details. > It just suggests to remove from the list the handlers a mode doesn't > want. Removing the, say, image/png handler from the list does not > require any knowledge how that handler accesses the clipboard nor how > it extracts PNG images from the clipboard. It just requires to know > the (trivial) fact that an image/png handler can interpret the > clipboard data as a PNG image. > > So I don't think I understand your reasoning. What did I miss? That the user does want PNG images is a "soft preference." If the clipboard only has image/png, the user would have the image/png data instead of none at all. You offered a solution for this: bind yank-media--registered-handlers in a custom command but having a variable would make it easy for the user to have a _global_ preference across major-modes. >> The major-mode authors would simply write handlers for all relevant >> data types and leave it to the user to choose the preferred type if >> more than one of them is handled by the major-mode. > > AFAIU, we were talking about situations where the major mode "knows > better" than the user, and doesn't want to leave the choice to users. No, the major-mode does not "know better" than user. It simply wants to respect the "soft" preferences of the user. >> But if the major-mode authors have to cater to the user's preferred data >> types by looking at TARGETS in their "major-mode-yank-media" command, >> that defeats the abstraction yank-media provides... > > I don't understand how. TARGETS include stuff like image/png and > text/html; how does looking at that defeat any abstractions, and what > abstractions are those? We cannot consider TARGETS to be an opaque > object anyway because then we won't be able to ask the user which of > the MIME types she wants to yank, nor apply any advance preferences of > the user. The MIME type the user wants to yank is asked by _yank-media_ currently. The major-mode has no part in this conversation, and this is exactly what we want to change. >> The entire point of using the library, IMHO, is to leave out this >> nasty business of handling the clipboard to a third party. > > What do you mean by "handling the clipboard"? In my mind, "handling > the clipboard" is what the handlers do, and my suggestion doesn't > change that, nor does it require any knowledge about their works. It > only requires to know that each MIME type has a handler, and removing > that handler from the list will prevent the clipboard data from being > interpreted as that MIME type. I admit that my memory failed me when I wrote that. I was under the impression that yank-media goes through a bit of effort to remove any nonsensical data types from TARGETS. So, it is not nasty as I initially meant. >> > If Org has its own ideas about what's best for the users in some >> > situations, and if the users agree with that, I don't see what is >> > wrong with that. The common interface presented by yank-media to >> > major modes is there so that major modes could use it in whichever >> > ways they think is best for their users. So I see no problems in >> > major modes deciding to prefer some handlers over others, not in >> > principle. >>=20 >> We do not disagree about this at all. What we do disagree on is the >> means by which to achieve this. If we could specify a filter function >> as a variable that filters out the available data types before >> presenting it to the user, the major-mode authors would be saved the >> burden of writing their yank-media-like command which requires the >> knowledge of obtaining TARGETS and potentially ignoring bogus types in >> it. > > How will that filter function be any different from what I propose? > You want to filter MIME types, I suggest filtering the handler, but > since each handler is uniquely identified by the MIME type it handles, > what exactly is the big difference? > > I feel there's some gross misunderstanding here, but what is it? I hope it is clear now. Two things can be achieved if we add such a filter function: 1. The user gets to specify her "soft" preference for available MIME types. This could be done by directly writing such a function herself or use whatever mechanism the major-mode offers to enforce this preference. I say "soft" because the user does not mind to use a "lesser" type if her preferred type is unavailable which would not be possible by specifically registered only image/USER-PREFERRED-TYPE. 2. The user gets to specify her preference globally, across major-modes. This would be hard if major-modes had to write their own "yank-media" command to cater to the user's preferences. The attached patch adds a variable to specify a filter function: yank-media-preferred-type-function. --=-=-= Content-Type: text/x-diff Content-Disposition: attachment; filename=yank-media-filter.patch diff --git a/lisp/yank-media.el b/lisp/yank-media.el index 563aae85419..30ede069769 100644 --- a/lisp/yank-media.el +++ b/lisp/yank-media.el @@ -29,6 +29,12 @@ (defvar yank-media--registered-handlers nil) +(defvar-local yank-media-preferred-type-function nil + "Function to select preferred mimetypes out of available ones. +If non-nil, this function is called with a list of mimetype that is +handled in the current buffer, and should return a list of preferred +types to use.") + ;;;###autoload (defun yank-media () "Yank media (images, HTML and the like) from the clipboard. @@ -49,18 +55,29 @@ yank-media (unless all-types (user-error "No handler in the current buffer for anything on the clipboard")) - ;; We have a handler in the current buffer; if there's just - ;; matching type, just call the handler. - (if (length= all-types 1) - (funcall (cdar all-types) (caar all-types) - (yank-media--get-selection (caar all-types))) - ;; More than one type the user for what type to insert. - (let ((type - (intern - (completing-read "Several types available, choose one: " - (mapcar #'car all-types) nil t)))) - (funcall (alist-get type all-types) - type (yank-media--get-selection type)))))) + ;; Remove types that are unwanted. + (let ((pref-types (funcall (if yank-media-preferred-type-function + yank-media-preferred-type-function + #'identity) + (mapcar #'car all-types)))) + (unless pref-types + (user-error + ;; FIXME: Improve the error message. + "No handler in the current buffer for preferred data types")) + ;; We have a handler in the current buffer; if there's just + ;; one preferred type, just call the handler. + (if (length= pref-types 1) + (let ((data (assq (car pref-types) all-types))) + (funcall (cdr data) (car pref-types) + (yank-media--get-selection (car pref-types)))) + ;; More than one type preferred, ask the user for what type to + ;; insert. + (let ((type + (intern + (completing-read "Several types available, choose one: " + pref-types nil t)))) + (funcall (alist-get type all-types) + type (yank-media--get-selection type))))))) (defun yank-media--find-matching-media (handled-type) (seq-filter --=-=-= Content-Type: text/plain Without the patch applied, copying an image from Firefox and using yank-media in an Org buffer asks me if I want image/png or image/jpeg. With that patch applied, and after evaluating (setq-local yank-media-preferred-type-function (lambda (types) (if (memq 'image/png types) (list 'image/png) types))) in an Org buffer, or message-mode buffer, I don't get asked that question. Afterwards, I copy a JPEG image using xclip then do yank-media. This yanks the image without asking me anything. This would not be possible had Org or message-mode only registered a handler for image/png. --=-=-=--