From mboxrd@z Thu Jan  1 00:00:00 1970
Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail
From: Visuwesh <visuweshm@gmail.com>
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 <eliz@gnu.org>
Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Oct 28 14:38:52 2024
Return-path: <emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org>
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 <emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org>)
	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 <emacs-devel-bounces@gnu.org>)
	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 <visuweshm@gmail.com>)
 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 <visuweshm@gmail.com>)
 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." <emacs-devel.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/emacs-devel>,
 <mailto:emacs-devel-request@gnu.org?subject=unsubscribe>
List-Archive: <https://lists.gnu.org/archive/html/emacs-devel>
List-Post: <mailto:emacs-devel@gnu.org>
List-Help: <mailto:emacs-devel-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/emacs-devel>,
 <mailto:emacs-devel-request@gnu.org?subject=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: <http://permalink.gmane.org/gmane.emacs.devel/324896>

[=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 <visuweshm@gmail.com>
>> 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.