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: Sun, 27 Oct 2024 19:11:06 +0200 Message-ID: <86iktd8o9h.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> 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="25901"; 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 Sun Oct 27 18:12:08 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 1t56oC-0006Zy-7r for ged-emacs-devel@m.gmane-mx.org; Sun, 27 Oct 2024 18:12:08 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t56nJ-0004UL-Ac; Sun, 27 Oct 2024 13:11:13 -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 1t56nH-0004U8-Ic for emacs-devel@gnu.org; Sun, 27 Oct 2024 13:11:11 -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 1t56nF-0001ie-CE; Sun, 27 Oct 2024 13:11:09 -0400 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=YU12lb7DTFgwc+fod5pZa0cJmuZdEAY0fFTvptPZsYU=; b=Zu4676TS0wl0ZyJQVybr ccZuvpFCkGJoPWEHAgrCaupF7lOwCOLW+eNZfghw9cFPJAmsOCzKbdj2Rb6TdM4qt++eAvWWxnxib rynMe86egsPwVY8jKpy7wQ7cMVI1PleTiiKbDLk12ww7mcHVYPMrfxeMifeoHm54kMJ4fjzhfzpTP 1hPlYWG5I0RZLcjiTglJJwHoPyrdiQuou2B4TWSv74bxExp/vMfQFdaYAeNcZ2YbhURZt0E9jT+vl m58dHen9jgmp7KwQsxD6tlJt4GE/GLv+ONnqxCOoP9PeiCL0GZr48rcua3t3GSHE9w1z4OIASU9gO XR8FK1w0xzfgRw==; In-Reply-To: <87sesh37ya.fsf@gmail.com> (message from Visuwesh on Sun, 27 Oct 2024 20:32:21 +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:324885 Archived-At: > 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 > > [ஞாயிறு அக்டோபர் 27, 2024] Eli Zaretskii wrote: > > >> > Examine the available TARGETS, then bind > >> > yank-media--registered-handlers to the appropriate value when invoking > >> > yank-media. > >> > >> 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? > > 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? > 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. > 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 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. > > 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. > > 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?