all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Visuwesh <visuweshm@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 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: Tue, 24 Sep 2024 19:07:25 +0530	[thread overview]
Message-ID: <871q19w4tm.fsf@gmail.com> (raw)
In-Reply-To: <867cb1dw2h.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 24 Sep 2024 16:23:50 +0300")

[செவ்வாய் செப்டம்பர் 24, 2024] Eli Zaretskii wrote:

>> From: Visuwesh <visuweshm@gmail.com>
>> Cc: pinmacs@cas.cat,  rpluim@gmail.com,  emacs-devel@gnu.org
>> Date: Tue, 24 Sep 2024 18:20:21 +0530
>> 
>> I haven't encountered many "multiple types available" scenario outside
>> of Firefox and LibreOffice.  In most cases, yank-media just does the
>> thing without interrupting me but when the uncommon case of "multiple
>> types available" crops up, I would like yank-media to choose the type I
>> want automatically for me.  In Org, I personally would make yank-media
>> choose image/png.  If you ask me for technical reasons to prefer
>> image/png specifically, I cannot give you a concrete answer. It might as
>> well be image/jpeg for all I care.  I simply do not want to be asked a
>> question when I'm focusing on writing.  The point of the user option is
>> to keep user interaction to a minimum.
>
> I think if PNG is supported by the running Emacs, it is always
> preferable.  (And we can come up with the list image formats ordered
> by their preference, and use that to find the first available one.)
>
> I do agree that in many/most cases having Emacs deduce the best format
> automatically is a very useful feature to have.  I also agree that it
> is useful to be able to see the list of available formats and choose
> from them.

So then we do agree.

> I just think that these two extremities is all we need, provided that
> we can come up with a good algorithm for deciding the "most
> appropriate format" in each case.

This is where we disagree: I think it would be best if we leave this
choice to the user.  I do not think it is possible to come up with a
"one size fits all" solution that works across all the handlers.  We
could leave the job of deciding the "most appropriate format" to the
major-mode but I am afraid it will only produce even more user options
which would be too chaotic to manage.



  reply	other threads:[~2024-09-24 13:37 UTC|newest]

Thread overview: 34+ 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 [this message]
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

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

  git send-email \
    --in-reply-to=871q19w4tm.fsf@gmail.com \
    --to=visuweshm@gmail.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=pinmacs@cas.cat \
    --cc=rpluim@gmail.com \
    /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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.