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.devel Subject: Re: yank-media: allow users to limit image types that can be inserted Date: Thu, 31 Oct 2024 10:24:48 +0200 Message-ID: <861pzw4r3j.fsf@gnu.org> 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> <87iktb171d.fsf@gmail.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15661"; mail-complaints-to="usenet@ciao.gmane.io" Cc: yantar92@posteo.net, pinmacs@cas.cat, rpluim@gmail.com, emacs-devel@gnu.org To: Visuwesh Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Oct 31 09:25:47 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 1t6QV0-0003re-Rs for ged-emacs-devel@m.gmane-mx.org; Thu, 31 Oct 2024 09:25:47 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t6QUB-0002IK-Em; Thu, 31 Oct 2024 04:24: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 1t6QUA-0002I5-9P for emacs-devel@gnu.org; Thu, 31 Oct 2024 04:24:54 -0400 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 1t6QU7-00076k-5K; Thu, 31 Oct 2024 04:24:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=YPGr92WUCLMNKzg0laLEeX7qQ0094Rs6GmSnjdHXE+Q=; b=W5S5F/gEgVH5 36in7ce1R5rpW8y6E+TAKwaO3uo2NluyO6slYsgZRLufiELOn/MYA+5iP2+gAdxxd4io4xZqaj2gM iyAFWwtqIhkWxpTAamkKNsMKi5RSljW9fmpUlE7IlslhBMv9b/L9jlzVGKpISoElJcwrEEdg8DsiC ML6w2pPNc/NtMy+STgC3kbu19iHMdr+x/B4f9p+0z/+h3FxjSl3r/BhiWEc/nPC+TtOZgv/A34BgU YfBIHUz8WPuqvIdRfnqoOWuZHAi1GW4cYAtNvmfscYWoCNOhPTKWEAE/TxVONVYtNO5JsTyFdNgY+ zPR/3a/pnVCCpDaHZVF6nQ==; In-Reply-To: <87iktb171d.fsf@gmail.com> (message from Visuwesh on Tue, 29 Oct 2024 16:59:34 +0530) 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:324957 Archived-At: > From: Visuwesh > Cc: yantar92@posteo.net, pinmacs@cas.cat, rpluim@gmail.com, > emacs-devel@gnu.org > Date: Tue, 29 Oct 2024 16:59:34 +0530 > > > 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. This (and the patch you suggest) completes the full circle of this discussion: it started when I said that such a global preference makes very little sense to me, based on my experience with yanking different data types in other applications. Users have no reason for such preferences, as they almost never have enough reasons to prefer one type over the others _globally_. The preference only makes sense in each specific case, and then asking the user to choose is exactly TRT, which we already do. > >> 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 might, though. And it already does, in fact: the few modes which support yank-media only register some of the handlers, but not others. Did you ask yourself why message.el registers only the handler for images, but not, say, for text/html? A major mode which doesn't support embedded images will probably refrain from installing image/* handlers, etc. > It simply wants to respect the "soft" preferences of the user. If we think such global preferences might make sense, we need to describe and discuss the use cases and reasons for having such preferences. Until now, the only reason I've heard was the desire to save some typing, i.e. let Emacs yank the one "preferred" media type without asking. If that is the reason, we could have instead a feature whereby "the best" or "the most appropriate" media type is yanked without asking; for example if yank-media is invoked with a prefix argument. (Or maybe the other way around: without the argument yank-media would yank "the best" media type.) This is what many other applications do, except that they do it when you type Ctrl-V, whereas we decided, and for good reasons, not to change how C-y work (though I don't see why some optional feature could not make C-y call yank-media). > > 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. Major mode _does_ have a part: it registers only the handlers it wants to support. So it determines, up front, which media types will be available, even if more of them are in the clipboard. > 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. Please tell me why on earth would you prefer PNG to JPEG when yanking, or vice versa. The result is an image displayed in the buffer, which is neither PNG nor JPEG. Why does it matter _for_you_personally_ which intermediate format will Emacs use as part of the yanking process? > 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. If we want to avoid the question when several image formats are available, we could teach Org, or Emacs in general, which formats to prefer. For example, JPEG is generally inferior because it's lossy, so we could have that hypothetical variant of yank-media which doesn't ask questions to always prefer PNG to JPEG if both are possible. This is IMO better than asking the users to decide that for Emacs. Anyway, since with this message we've made a full circle, let me summarize my opinions on this: . I think we should add to Emacs rules for preferring one media format over the others when several are available and supported . Such rules should be customized by major modes based on their features and preferences (e.g., a mode that has no support for faces might prefer plain text to other textual formats) . I think we should have a variant of yank-media that yanks "the best" of the available formats without asking, based on the above rules If after all of this people still want a global "preference", I won't mount the barricades to fight that, although, as I explained, such a global preference makes little sense to me, and sounds like an inferior replacement for the missing built-in preference rules I think we should have.