[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#75116: [PATCH] Make 'yank-media' autoselect the best media type
From: |
Visuwesh |
Subject: |
bug#75116: [PATCH] Make 'yank-media' autoselect the best media type |
Date: |
Mon, 06 Jan 2025 10:07:12 +0530 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
[சனி டிசம்பர் 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.
- bug#75116: [PATCH] Make 'yank-media' autoselect the best media type,
Visuwesh <=