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: Mon, 28 Oct 2024 19:07:49 +0530 Message-ID: <877c9s2vrm.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: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19322"; 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 Mon Oct 28 14:38:52 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 1t5PxI-0004oi-W5 for ged-emacs-devel@m.gmane-mx.org; Mon, 28 Oct 2024 14:38:49 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t5PwX-0006Q0-Oy; Mon, 28 Oct 2024 09:38:01 -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 1t5PwW-0006Pp-Bu for emacs-devel@gnu.org; Mon, 28 Oct 2024 09:38:00 -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 1t5PwU-0004b0-JL; Mon, 28 Oct 2024 09:38:00 -0400 Original-Received: by mail-pl1-x641.google.com with SMTP id d9443c01a7336-20c693b68f5so44061115ad.1; Mon, 28 Oct 2024 06:37:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1730122676; x=1730727476; darn=gnu.org; h=content-transfer-encoding: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=2obmqrQ+IhQWqu6LbeV2hIU6wz7efQvAi8ywfNUqkks=; b=cSSMABljKjZAV1IehnkfuG23dyt0S/+rQPUPR0WAuUPZHd5Gd2eSs/TIEgHXMhTdYZ Ru+eGSh/P9lwFjmCCuA0QSaSa+bHkPDQFwFOhEkOnaraTrAprim92NH/IMaPCaGw48ed me/+W0z69a8zUE3Xreoduvi1NIxyXVFYysu412VzdY9le0Yu1LJyQNyJl1TxrjzUl/Pn jwVf7sofaWDuQ/Zp83DZeih6Si2anDu+3AETlQDKX7xc/g8P1m4myY96ydnnfVakirwv U4fsJG+AJpN1oK4zOjsVdgYLctVKW0SfoX2KOn1e3dtUiKOBhhBoGL67IY0we2mcnJ+S PypA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730122676; x=1730727476; h=content-transfer-encoding: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=2obmqrQ+IhQWqu6LbeV2hIU6wz7efQvAi8ywfNUqkks=; b=syZyyFvuqAwexeDFlbr1otvP808dByVK36ZhEzpqunA8UoRVswCcGA8wQLfostNJ8Y +4dJpGqyjIe2nKmbLyBI2b589d9PWSOPVyD+eXg33lSNcWUMb//C3HdlYjnkRD/scpC6 OuQCFRBpdpKHqbHwQyt11EZjR/AvI38G6JKLg/p+jW+e2x6XnlsBmI74O1RWR0vEX4xr uPjHZHdtuJhVAU0uq1RsqrDkpCDqcEGRRjZumIO7Sl4K+a445LDEGU1f5qgISyrevIwP ZTl8U7f/WHKuBau+xs1hEsooDndZQIvZuaDbHuV6VtjsQCJ+k29NFUS1n0p5vWhRVhmi 31sA== X-Forwarded-Encrypted: i=1; AJvYcCW6+BEwLwrrBm0TsECuTcHZxF9MwZ8TxY/WHGCWfeU43h2nKxK/EEGKuiQcoN+tGRz1urypG6aAwWNVxw==@gnu.org X-Gm-Message-State: AOJu0YySlYDvaw9ZmKcJWnVEJbnwwmVMM08TfSJnhN2AGqVEh8N5RMTO VzUAyO/rsXmUvWG3sVHwHXSCo2YsS/pQNCsD72It7fL9X5yX3z6PlgXb76M8 X-Google-Smtp-Source: AGHT+IFAv8gqMZ2E/IqfNJEV1WU+at2f0cj4Nhi1Tk+koTcYDRonlPZFm/f5PrGWXirZve37SXCoGw== X-Received: by 2002:a17:903:2289:b0:20b:7ec0:ee21 with SMTP id d9443c01a7336-210c68cf5a9mr123374855ad.19.1730122675229; Mon, 28 Oct 2024 06:37:55 -0700 (PDT) Original-Received: from localhost ([115.240.90.130]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-210bbf44743sm50323845ad.21.2024.10.28.06.37.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 28 Oct 2024 06:37:54 -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:324896 Archived-At: [=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? > >> 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. >>=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 feel the same too. I believe it would be more productive if I proposed a patch of what I am suggesting so that things will be more clear. I will try to post one as soon as time permits, and will answer rest of the questions you've raised in your message then.