unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Visuwesh <visuweshm@gmail.com>
Cc: yantar92@posteo.net, pinmacs@cas.cat, rpluim@gmail.com,
	emacs-devel@gnu.org
Subject: Re: yank-media: allow users to limit image types that can be inserted
Date: Sun, 27 Oct 2024 19:11:06 +0200	[thread overview]
Message-ID: <86iktd8o9h.fsf@gnu.org> (raw)
In-Reply-To: <87sesh37ya.fsf@gmail.com> (message from Visuwesh on Sun, 27 Oct 2024 20:32:21 +0530)

> 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
> 
> [ஞாயிறு அக்டோபர் 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?



  reply	other threads:[~2024-10-27 17:11 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-22 16:53 yank-media: allow users to limit image types that can be inserted pinmacs
2024-09-23 11:20 ` Eli Zaretskii
2024-09-23 13:46   ` Visuwesh
2024-09-23 14:30     ` Eli Zaretskii
2024-09-23 15:06       ` Visuwesh
2024-09-23 15:48         ` Eli Zaretskii
2024-09-23 15:09       ` Robert Pluim
2024-09-23 15:14         ` Visuwesh
2024-09-23 15:20           ` Robert Pluim
2024-09-23 15:58           ` Eli Zaretskii
2024-09-24  5:00             ` Visuwesh
2024-09-24  5:10               ` Visuwesh
2024-09-24 11:57               ` Eli Zaretskii
2024-09-24 12:42                 ` Visuwesh
2024-09-23 15:54         ` Eli Zaretskii
2024-09-23 16:10           ` Robert Pluim
2024-09-23 16:34             ` Eli Zaretskii
2024-09-23 18:00               ` pinmacs
2024-09-23 18:35                 ` Eli Zaretskii
2024-09-23 20:45                   ` Pedro
2024-09-23 21:08                   ` pinmacs
2024-09-24  8:15                     ` Robert Pluim
2024-09-24 11:30                     ` Eli Zaretskii
2024-09-24 12:18                       ` Robert Pluim
2024-09-24 13:08                         ` Eli Zaretskii
2024-09-24 13:38                           ` Visuwesh
2024-09-24 13:50                             ` Eli Zaretskii
2024-09-24  5:08                   ` Visuwesh
2024-09-24 12:00                     ` Eli Zaretskii
2024-09-24 12:50                       ` Visuwesh
2024-09-24 13:23                         ` Eli Zaretskii
2024-09-24 13:37                           ` Visuwesh
2024-10-26 17:27                       ` Ihor Radchenko
2024-10-26 19:09                         ` Eli Zaretskii
2024-10-27  8:17                           ` Ihor Radchenko
2024-10-27  9:14                             ` Eli Zaretskii
2024-10-27  9:36                               ` Visuwesh
2024-10-27 10:09                                 ` Eli Zaretskii
2024-10-27 15:02                                   ` Visuwesh
2024-10-27 17:11                                     ` Eli Zaretskii [this message]
2024-10-28 13:37                                       ` Visuwesh
2024-10-29 11:29                                       ` Visuwesh
2024-10-28 18:39                               ` Ihor Radchenko
2024-10-28 18:50                                 ` Eli Zaretskii
2024-09-23 18:11               ` Eli Zaretskii
2024-09-24  8:38                 ` Robert Pluim

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86iktd8o9h.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=pinmacs@cas.cat \
    --cc=rpluim@gmail.com \
    --cc=visuweshm@gmail.com \
    --cc=yantar92@posteo.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).