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: Sun, 27 Oct 2024 20:32:21 +0530 Message-ID: <87sesh37ya.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> 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="17857"; 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 Sun Oct 27 16:03:17 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 1t54nU-0004SO-8F for ged-emacs-devel@m.gmane-mx.org; Sun, 27 Oct 2024 16:03:16 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t54mn-0000IG-04; Sun, 27 Oct 2024 11:02:33 -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 1t54mj-0000Hw-PF for emacs-devel@gnu.org; Sun, 27 Oct 2024 11:02:29 -0400 Original-Received: from mail-pl1-x644.google.com ([2607:f8b0:4864:20::644]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1t54mi-0007lW-8V; Sun, 27 Oct 2024 11:02:29 -0400 Original-Received: by mail-pl1-x644.google.com with SMTP id d9443c01a7336-20ca1b6a80aso33126445ad.2; Sun, 27 Oct 2024 08:02:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1730041346; x=1730646146; 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=CAEo6V62zfHUjwVOVnaUW8O2vjOsdH+8m3gdr/Mudp0=; b=XQLcTk9EqUKw37nafZ4kGPG56ChxZZ5kaXp0t87kN6qzLc/lVFmBCALfePqfCUFXwo hfYrJGNsdgI3Fs4iTgY5GcXWOUyc1MVKp/b3F2KbSMZGx0LGaUAEh0Q0dG0GboepoCSe EPUhfy02lgpvFp0NaKVsTHjeOFPIFRxsEvMfQwQk1P/Uq2ML0TpA5JOSmYn72laOxW/j xn7oqkL8FeZYoi3/fms3pL44tGxd6btjqBfImufznOUUD+/nuNLWP3lddzleeqVKwjFq RooD+azjaElDnv/JJC08x8q1MDQzo6ixkBGC4zTkuOfQjxFCQZTo8ez1h8+B1+qNfw2P NZgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730041346; x=1730646146; 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=CAEo6V62zfHUjwVOVnaUW8O2vjOsdH+8m3gdr/Mudp0=; b=aI+0axc0bGwJuk6iQsa4gzOu3OVH/pwFz/EgyFv4qUBUDP4r/tqHmrieOU5Sj1N275 4evPRxB2O4ORyLrzuoIhJOpUlAkx35VHhUw/aFs8A2Lp9703StrBEE5LvJcGBQeEyEzJ WODMAAxieVn+oz+Zu3Bcpnn91sy5BGZZjCREdBLMuhJjhgf5UfIb5DTkIlxbjvbzoyIN +XJ1bbojdd+wZ8dQ5tPC6uhRr4wChiwIUBAHp5NlsUR/pYA0k5sZmfzOT4UVkZwu/PdG 0E2AkR7FIdy7y+Oayn8IELAK8g6BztTEYbWLvV5PEc3SPuQlhcrzGicmxLJPxIYphKUB htPw== X-Forwarded-Encrypted: i=1; AJvYcCVfCs7ztSyEw58yhCtQ/5DlS7EEg7KnocqFcGdzsZXoK7k/+eCyWg/8U+VgCL98honFRCo0Oofz4uTkKw==@gnu.org X-Gm-Message-State: AOJu0Yy0+zhWxi/2MYN3BWsJO6MPPqsAzHiU1VdwU9zK4VGPjdx8Bu7c oxFEEjj9Myp9eXxYNixHwCWKacmA6pWjBi4p1xoSAg8Uv5r+S1jJewVWOSLG X-Google-Smtp-Source: AGHT+IH3ZNIrdO/Yx2IwOlGbfbmJ3c1C9icqhrF4AkkkqARUFgoKKZm4ppwqeZ5OUrj79ZIZUckUEA== X-Received: by 2002:a17:903:230e:b0:20c:890c:2f76 with SMTP id d9443c01a7336-210c68d4363mr92133765ad.16.1730041345858; Sun, 27 Oct 2024 08:02:25 -0700 (PDT) Original-Received: from localhost ([1.7.159.70]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-210bc0179e6sm36276895ad.168.2024.10.27.08.02.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 27 Oct 2024 08:02:25 -0700 (PDT) In-Reply-To: <86v7xdamck.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 27 Oct 2024 12:09:31 +0200") Received-SPF: pass client-ip=2607:f8b0:4864:20::644; envelope-from=visuweshm@gmail.com; helo=mail-pl1-x644.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:324884 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: Ihor Radchenko , pinmacs@cas.cat, >> rpluim@gmail.com, emacs-devel@gnu.org >> Date: Sun, 27 Oct 2024 15:06:36 +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 >> >> From: Ihor Radchenko >> >> Cc: visuweshm@gmail.com, pinmacs@cas.cat, rpluim@gmail.com, emacs-dev= el@gnu.org >> >> Date: Sun, 27 Oct 2024 08:17:22 +0000 >> >>=20 >> >> Eli Zaretskii writes: >> >>=20 >> >> 1. clipboard contains 2 MIME types: image/png, image/bmp >> >> 2. clipboard contains 1 MIME type: image/png >> >> 3. clipboard contains 1 MIME type: image/bmp >> >>=20 >> >> We want to handle all three scenarios in the following way: >> >> 1. Select image/png (prefer it over image/bmp) >> >> 2. Select image/png >> >> 3. Select image/bmp (there is no image/png that we would prefer other= wise) >> >>=20 >> >> In all three cases, we do not want to prompt user about mimetype choi= ce. >> >>=20 >> >> How can we do it using the existing Elisp API? >> > >> > Examine the available TARGETS, then bind >> > yank-media--registered-handlers to the appropriate value when invoking >> > 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? 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. 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. 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... The entire point of using the library, IMHO, is to leave out this nasty business of handling the clipboard to a third party. >> This approach also means that we would end up with org-yank-media, >> html-yank-media, etc. which does not sound better. > > 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.