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: yantar92@posteo.net, pinmacs@cas.cat, rpluim@gmail.com,
	75116@debbugs.gnu.org
Subject: bug#75116: [PATCH] Make 'yank-media' autoselect the best media type
Date: Mon, 06 Jan 2025 10:07:12 +0530	[thread overview]
Message-ID: <87bjwkbls7.fsf@gmail.com> (raw)
In-Reply-To: <86r05sro63.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 28 Dec 2024 14:24:04 +0200")

[சனி டிசம்பர் 28, 2024] Eli Zaretskii wrote:

>> >> +(defvar yank-media-preferred-types
>> >> +  `(;; Check first since LibreOffice also puts a PNG image in the
>> >> +    ;; clipboard when a table cell is copied.
>> >> +    application/x-libreoffice-tsvc
>> >> +    ;; Give PNG more priority.
>> >> +    image/png
>> >> +    image/jpeg
>> >> +    ;; These are files copied/cut to the clipboard from a file manager.
>> >> +    ,(lambda (mimetypes)
>> >> +       (seq-find (lambda (type)
>> >> +                (string-match-p "x-special/\\(gnome\\|KDE\\|mate\\)-files"
>> >> +                                (symbol-name type)))
>> >> +              mimetypes))
>> >> +    ;; FIXME: We should have a way to handle text/rtf.
>> >> +    text/html)
>> >
>> > Not sure I understand the value you suggest.  It seems to lack many
>> > important types.  
>> 
>> These are media types for which support for yank-media already exists:
>
> I thought we should have here as many media types as possible,
> regardless of their support, because this variable expresses the
> relative priorities of the types.  Major modes which add handlers
> should not need to also modify the value of this variable
> unnecessarily, no?

I agree with you but I am limited by my awareness of these potential
media types.  I would be happy to add more if someone points me to them.

>> > Also, aren't at least some of the types system-dependent?
>> 
>> Yes, definitely.  x/special-gnome-files and
>> application/x-libreoffice-tsvc are system- and software-dependent resp.
>> This was one of my comments addressed in the message I posted to
>> emacs-devel:
>> 
>>      The mimetype used for cut/copied files only works in Linux
>>      environments.  If other platforms can present such file:// links in
>>      the clipboard and Emacs supports it, we would need to add it to the
>>      list too.
>> 
>> If we want platform-agnostic types, I assume we need an abstraction
>> layer on top that would present the clipboard data in a uniform manner.
>> I do not have the means to work on this since I only use Linux systems.
>
> I just thought about having the value depend on the platform.

Ah, understood.

>> >> +    (setq pref-type (and (null noselect)
>> >> +                         (funcall yank-media-autoselect-function
>> >> +                                  (mapcar #'car all-types))))
>> >> +    (cond
>> >> +     ;; We have one preferred mime type so use it unconditionally.
>> >> +     ((and pref-type (symbolp pref-type))
>> >> +      (funcall (cdr (assq pref-type all-types)) pref-type
>> >> +               (yank-media--get-selection pref-type)))
>> >> +     ;; The user chose to not autoselect and there's just a single type,
>> >> +     ;; just call the handler.
>> >> +     ((and (null pref-type) (length= all-types 1))
>> >> +      (funcall (cdar all-types) (caar all-types)
>> >> +               (yank-media--get-selection (caar all-types))))
>> >
>> > This goes against what the doc string says.  And I think the doc
>> > string describes a better behavior: if the user asked not to
>> > auto-select, we shouldn't, even if there's just one type available.
>> > We should instead ask the user whether to yank that type, because the
>> > user could decide she doesn't want that type, even it it's the only
>> > one.
>> >
>> > Also, I think we should show some message if
>> > yank-media-autoselect-function returns nil.  AFAIU, the code you
>> > posted silently does nothing, which IMO is not the best UI.
>> 
>> I want to ensure we are on the same page wrt UI here:
>> 
>>     User asks to autoselect:
>>       1. autoselect-function (a-s-f) returns one media type: we yank it.
>
> Yes.
>
>>       2. a-s-f returns multiple media types: we ask the user which one
>>          to yank.
>
> No, we use the first one.

Doesn't this mean there is pratically no difference between (1) and (2)?
Ihor, is this okay?  Or did you have something else in mind when you
asked for the possibility to return multiple types?

>>       3. a-s-f returns nil.  We show a message and do what?
>
> We show a message and do nothing.
>
>>     User asks not to autoselect:
>>       4. (length all-types) = 1: We show the media type and ask if she
>>          wants to yank it.
>
> Yes.
>
>>       5. (length all-types) > 1: We ask for the media type to yank.
>
> Yes.
>
>> Excepting case (3), does the other cases sound good?
>
> See above regarding my opinions.

Thank you, they are clear now.





  reply	other threads:[~2025-01-06  4:37 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-26 12:27 bug#75116: [PATCH] Make 'yank-media' autoselect the best media type Visuwesh
2024-12-26 15:49 ` Eli Zaretskii
2024-12-27  8:58   ` Visuwesh
2024-12-28 12:24     ` Eli Zaretskii
2025-01-06  4:37       ` Visuwesh [this message]
2025-01-06 14:10         ` Eli Zaretskii
2025-01-06 18:33         ` Ihor Radchenko
2025-01-06 18:50           ` Eli Zaretskii
2025-01-06 19:05             ` Ihor Radchenko
2025-01-06 19:15               ` Eli Zaretskii

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=87bjwkbls7.fsf@gmail.com \
    --to=visuweshm@gmail.com \
    --cc=75116@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=pinmacs@cas.cat \
    --cc=rpluim@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 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.