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: Mon, 28 Oct 2024 20:50:05 +0200 Message-ID: <868qu86p0i.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> <8734kgkr7d.fsf@localhost> 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="35260"; mail-complaints-to="usenet@ciao.gmane.io" Cc: visuweshm@gmail.com, pinmacs@cas.cat, rpluim@gmail.com, emacs-devel@gnu.org To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Oct 28 19:51:40 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 1t5Uq3-00090x-RC for ged-emacs-devel@m.gmane-mx.org; Mon, 28 Oct 2024 19:51:39 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t5UpD-0007uP-7v; Mon, 28 Oct 2024 14:50:47 -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 1t5UpA-0007uC-Fs for emacs-devel@gnu.org; Mon, 28 Oct 2024 14:50:44 -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 1t5Up7-0006e6-Px; Mon, 28 Oct 2024 14:50:41 -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=mA7I/GuHZfVUtWGGrf6tgtjHArbGToj2+6nOaLEQNY0=; b=Qiw98MY17G/pftm78Z4t OLF+6gQ3DvhnKJRdLLADEZbHblWUvgK/rkViMW3mF2pVTt+2PeJCDJt7LAfuM5BEwUDDZUt+bY4bv zJTNdKvTpB0+wfJD2k8BSe0/dGDE6yOs8kU07qUmq4p07Fra9gW4OtKw1aAIjJD7U5gHDdoA4kDME iDpAqENKDA4/E8mWqpo34i5xmwrYjzbRW6rRE1b00SzKWSIa6HwUS5U7h+0hShByOMu8MkjV77Gj+ a3t5tWwxbPM9GTxvSiUgL3gd8aVaFqBht9fvEyxmSmHvtOTPT6M6M2xCk80CO5eCXpfOJOKe2VyEx G3IFY3bkBq8PHg==; In-Reply-To: <8734kgkr7d.fsf@localhost> (message from Ihor Radchenko on Mon, 28 Oct 2024 18:39:02 +0000) 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:324901 Archived-At: > From: Ihor Radchenko > Cc: visuweshm@gmail.com, pinmacs@cas.cat, rpluim@gmail.com, emacs-devel@gnu.org > Date: Mon, 28 Oct 2024 18:39:02 +0000 > > Eli Zaretskii writes: > > > Examine the available TARGETS, then bind > > yank-media--registered-handlers to the appropriate value when invoking > > yank-media. > > I am surprised that you are suggesting to bind an internal variable that > does not even have a documented format. Moreover, it is even > deliberately hidden behind `yank-media-handler' wrapper. This is all very new, and has yet to be tested by the relevant use cases. The initial implementation was basically for a single platform, and thus is from my POV heavily skewed towards that single platform. Thus, I don't see the fact that some variable was deemed as internal by the original implementor as something we cannot change if we decide it's useful for applications. In general, how to control which MIME types are used or presented to users was not part of the original implementation and AFAIR was never discussed. The code we have basically assumes that all the MIME types are relevant and could/should be used in any order. Based on what I see on various platforms with many different applications that support the clipboard, I think this is quite naïve, so we must extend what we have to support more control, and that might legitimately call for reassessment of the internal vs public knobs.