GNU bug report logs - #71909
30.0.60; Can not use yank-media for pasting image from clipboad in org-mode on Windows platform

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 71909 in the body.
You can then email your comments to 71909 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eason Huang <aqua0210 <at> foxmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.0.60; Can not use yank-media for pasting image from clipboad in
 org-mode on Windows platform
Date: Wed, 03 Jul 2024 12:45:17 +0800

Hi Emacs,

Rencently I tried to use yank-media for pasting image from clipboad in
org-mode, It works as expected on Linux system, but it doesn't works on
Windows 10 and Windows 11.

Does it mean that it doesn't support Windows platform?

Steps to reproduce:

1. Start Emacs with `emacs -Q`
2. C-x C-f ~/test.org to open a file in org-mode
3. Copy any image in clipboard
4. M-x yank-media on the test.org file, will get following message:
```
user-error: No handler in the current buffer for anything on the
clipboard
```

5. try M-x yank-media-types, only get the `primary:STRING`





In GNU Emacs 30.0.60 (build 1, x86_64-w64-mingw32, git sha1 b2d99c0d0aa)
of 2024-07-01 built on DESKTOP-VIHFE84

Windowing system distributor 'Microsoft Corp.', version 10.0.19045
System Description: Microsoft Windows 10 Pro (v10.0.2009.19045.4529)

Configured using:
 'configure --without-native-compilation --without-dbus'

Configured features:
ACL GIF GMP GNUTLS HARFBUZZ JPEG LCMS2 LIBXML2 MODULES NOTIFY W32NOTIFY
PDUMPER PNG RSVG SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS
TREE_SITTER WEBP XPM ZLIB

Important settings:
  value of $LANG: CHS
  locale-coding-system: cp936

Major mode: Org

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  minibuffer-regexp-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug vc-git diff-mode track-changes
easy-mmode vc-dispatcher oc-basic cl-extra help-mode org-element
org-persist org-id org-refile org-element-ast inline avl-tree generator
ol-eww eww xdg url-queue mm-url ol-rmail ol-mhe ol-irc ol-info ol-gnus
nnselect gnus-art mm-uu mml2015 mm-view mml-smime smime gnutls dig
gnus-sum shr pixel-fill kinsoku url-file svg dom gnus-group gnus-undo
gnus-start gnus-dbus dbus xml gnus-cloud nnimap nnmail browse-url url
url-proxy url-privacy url-expand url-methods url-history url-cookie
generate-lisp-file url-domsuf url-util url-parse auth-source cl-seq
eieio eieio-core cl-macs json map byte-opt gv bytecomp byte-compile
url-vars mail-source utf7 nnoo parse-time gnus-spec gnus-int gnus-range
message sendmail mailcap yank-media puny rfc822 mml mml-sec
password-cache epa derived epg rfc6068 epg-config mm-decode mm-bodies
mm-encode mail-parse rfc2231 rfc2047 rfc2045 ietf-drums mailabbrev
gmm-utils mailheader gnus-win gnus nnheader gnus-util
text-property-search mail-utils range mm-util mail-prsvr wid-edit
ol-docview doc-view filenotify jka-compr image-mode exif dired
dired-loaddefs ol-bibtex bibtex iso8601 ol-bbdb ol-w3m ol-doi
org-link-doi org ob ob-tangle ob-ref ob-lob ob-table ob-exp org-macro
org-src sh-script smie treesit executable ob-comint org-pcomplete
pcomplete comint ansi-osc ansi-color ring org-list org-footnote
org-faces org-entities time-date subr-x noutline outline icons
org-version ob-emacs-lisp ob-core ob-eval org-cycle org-table ol rx
org-fold org-fold-core org-keys oc org-loaddefs thingatpt find-func
cal-menu calendar cal-loaddefs org-compat org-macs format-spec
cl-loaddefs cl-lib china-util rmc iso-transl tooltip cconv eldoc paren
electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
touch-screen dos-w32 ls-lisp disp-table term/w32-win w32-win w32-vars
term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode lisp-mode prog-mode register
page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer nadvice seq simple cl-generic indonesian philippine
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads w32notify w32 lcms2 multi-tty move-toolbar make-network-process
emacs)

Memory information:
((conses 16 203309 45833) (symbols 48 21586 3) (strings 32 69962 3229)
 (string-bytes 1 1824468) (vectors 16 38531)
 (vector-slots 8 453695 13842) (floats 8 275 135) (intervals 56 587 0)
 (buffers 992 13))

-- 
Eason Huang

Message #8 received at 71909 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Eason Huang <aqua0210 <at> foxmail.com>
Cc: 71909 <at> debbugs.gnu.org
Subject: Re: bug#71909: 30.0.60;
 Can not use yank-media for pasting image from clipboad in org-mode on
 Windows platform
Date: Wed, 03 Jul 2024 14:19:38 +0300

severity 71909 wishlist
thanks

> From: Eason Huang <aqua0210 <at> foxmail.com>
> Date: Wed, 03 Jul 2024 12:45:17 +0800
> 
> Rencently I tried to use yank-media for pasting image from clipboad in
> org-mode, It works as expected on Linux system, but it doesn't works on
> Windows 10 and Windows 11.
> 
> Does it mean that it doesn't support Windows platform?

Yes, Emacs doesn't (yet) support this on MS-Windows.  Patches welcome
to add such a support.

> Steps to reproduce:
> 
> 1. Start Emacs with `emacs -Q`
> 2. C-x C-f ~/test.org to open a file in org-mode
> 3. Copy any image in clipboard
> 4. M-x yank-media on the test.org file, will get following message:
> ```
> user-error: No handler in the current buffer for anything on the
> clipboard
> ```
> 
> 5. try M-x yank-media-types, only get the `primary:STRING`

That's the expected result with the current codebase, yes.

Message #13 received at 71909 <at> debbugs.gnu.org (full text, mbox):

From: Cecilio Pardo <cpardo <at> imayhem.com>
To: 71909 <at> debbugs.gnu.org
Subject: Re: bug#71909: 30.0.60;
Date: Sat, 5 Oct 2024 14:28:35 +0200

I'll be working on this, if no one else is.

Message #16 received at 71909 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Cecilio Pardo <cpardo <at> imayhem.com>
Cc: 71909 <at> debbugs.gnu.org
Subject: Re: bug#71909: 30.0.60;
Date: Sat, 05 Oct 2024 15:33:39 +0300

> Date: Sat, 5 Oct 2024 14:28:35 +0200
> From: Cecilio Pardo <cpardo <at> imayhem.com>
> 
> 
> I'll be working on this, if no one else is.

Thanks in advance.

Btw, if you are looking for significant enhancements to Emacs on
Windows, then support for color fonts (which needs to use Direct2D,
AFAIU) will be greatly appreciated.

Message #19 received at 71909 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: cpardo <at> imayhem.com
Cc: 71909 <at> debbugs.gnu.org
Subject: Re: bug#71909: 30.0.60;
Date: Sat, 05 Oct 2024 15:42:11 +0300

> Cc: 71909 <at> debbugs.gnu.org
> Date: Sat, 05 Oct 2024 15:33:39 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> > Date: Sat, 5 Oct 2024 14:28:35 +0200
> > From: Cecilio Pardo <cpardo <at> imayhem.com>
> > 
> > 
> > I'll be working on this, if no one else is.
> 
> Thanks in advance.

Btw, perhaps we should discuss the implementation ideas you have
first.  I'm guessing you are going to somehow map the clipboard
formats defined by Windows to MIME types, then I wonder what should we
do with the virtually open-ended set of Windows clipboard formats.

Or maybe you have other ideas?

Message #22 received at 71909 <at> debbugs.gnu.org (full text, mbox):

From: Cecilio Pardo <cpardo <at> imayhem.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 71909 <at> debbugs.gnu.org
Subject: Re: bug#71909: 30.0.60;
Date: Sat, 5 Oct 2024 19:14:20 +0200

On 05/10/2024 14:42, Eli Zaretskii wrote:

> Btw, perhaps we should discuss the implementation ideas you have
> first.  I'm guessing you are going to somehow map the clipboard
> formats defined by Windows to MIME types, then I wonder what should we
> do with the virtually open-ended set of Windows clipboard formats.
> 
> Or maybe you have other ideas?

Yes, I was thinking about mapping some of the formats, and ignoring the 
rest. Looking at the lisp files inside emacs, only these formats seem to 
be in use:

image/*
text/html (which is treated as text in sgml-mode)
x/special-\\(?:gnome\\|KDE\\|mate\\)-files

So CF_BITMAP and CF_HDROP, and maybe CF_HTML would cover all. Metafiles 
could be converted to bitmaps.

As for other formats, other than offer them as application/octet-stream, 
I don't know.

Message #25 received at 71909 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Cecilio Pardo <cpardo <at> imayhem.com>
Cc: 71909 <at> debbugs.gnu.org
Subject: Re: bug#71909: 30.0.60;
Date: Sat, 05 Oct 2024 22:31:47 +0300

> Date: Sat, 5 Oct 2024 19:14:20 +0200
> Cc: 71909 <at> debbugs.gnu.org
> From: Cecilio Pardo <cpardo <at> imayhem.com>
> 
> On 05/10/2024 14:42, Eli Zaretskii wrote:
> 
> > Btw, perhaps we should discuss the implementation ideas you have
> > first.  I'm guessing you are going to somehow map the clipboard
> > formats defined by Windows to MIME types, then I wonder what should we
> > do with the virtually open-ended set of Windows clipboard formats.
> > 
> > Or maybe you have other ideas?
> 
> Yes, I was thinking about mapping some of the formats, and ignoring the 
> rest. Looking at the lisp files inside emacs, only these formats seem to 
> be in use:
> 
> image/*
> text/html (which is treated as text in sgml-mode)
> x/special-\\(?:gnome\\|KDE\\|mate\\)-files
> 
> So CF_BITMAP and CF_HDROP, and maybe CF_HTML would cover all. Metafiles 
> could be converted to bitmaps.
> 
> As for other formats, other than offer them as application/octet-stream, 
> I don't know.

If you invoke "M-: (gui-get-selection 'CLIPBOARD 'TARGETS) RET" after
copying something to the clipboard, you will see some very weird
format names there.  For the standard formats, we convert them to
something similar to what X Window system produces (see
w32-selection-targets), but the rest are returned as-is.  For example,
after copying an image from Firefox, I get this as the return value of
the above evaluation:

  [DataObject text/html HTML\ Format text/_moz_htmlinfo text/_moz_htmlcontext application/x-moz-file-promise-url application/x-moz-file-promise-dest-filename FILE_NAMES Preferred\ DropEffect application/x-moz-nativeimage DIB Ole\ Private\ Data BITMAP nil]

There's no image/* here, only DIB and BITMAP (which correspond to
CF_DIB and CF_BITMAP clipboard formats).  There are also a lot of
text/* formats, but they are all non-standard, except, perhaps,
text/html.  Do you have ideas how to select the proper format and how
to yank the data?

What do the x/special-* formats correspond to on Windows?

Message #28 received at 71909 <at> debbugs.gnu.org (full text, mbox):

From: Cecilio Pardo <cpardo <at> imayhem.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 71909 <at> debbugs.gnu.org
Subject: Re: bug#71909: 30.0.60;
Date: Sat, 5 Oct 2024 23:24:09 +0200

On 05/10/2024 21:31, Eli Zaretskii wrote:

> If you invoke "M-: (gui-get-selection 'CLIPBOARD 'TARGETS) RET" after
> copying something to the clipboard, you will see some very weird
> format names there.  For the standard formats, we convert them to
> something similar to what X Window system produces (see
> w32-selection-targets), but the rest are returned as-is.  For example,
> after copying an image from Firefox, I get this as the return value of
> the above evaluation:
> 
>    [DataObject text/html HTML\ Format text/_moz_htmlinfo text/_moz_htmlcontext application/x-moz-file-promise-url application/x-moz-file-promise-dest-filename FILE_NAMES Preferred\ DropEffect application/x-moz-nativeimage DIB Ole\ Private\ Data BITMAP nil]
> 
> There's no image/* here, only DIB and BITMAP (which correspond to
> CF_DIB and CF_BITMAP clipboard formats).  There are also a lot of
> text/* formats, but they are all non-standard, except, perhaps,
> text/html.  Do you have ideas how to select the proper format and how
> to yank the data?

> What do the x/special-* formats correspond to on Windows?

We would convert the BITMAP format to image/png, and FILE_NAMES to
x-special/gnome-copied-files, to be compatible with what org-mode does 
now. The offer to yank-media would then be text/html, image/png, and 
x-special/gnome-copied-files, ignoring the rest of formats.

Message #31 received at 71909 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Cecilio Pardo <cpardo <at> imayhem.com>
Cc: 71909 <at> debbugs.gnu.org
Subject: Re: bug#71909: 30.0.60;
Date: Sun, 06 Oct 2024 08:59:39 +0300

> Date: Sat, 5 Oct 2024 23:24:09 +0200
> From: Cecilio Pardo <cpardo <at> imayhem.com>
> Cc: 71909 <at> debbugs.gnu.org
> 
> On 05/10/2024 21:31, Eli Zaretskii wrote:
> 
> > If you invoke "M-: (gui-get-selection 'CLIPBOARD 'TARGETS) RET" after
> > copying something to the clipboard, you will see some very weird
> > format names there.  For the standard formats, we convert them to
> > something similar to what X Window system produces (see
> > w32-selection-targets), but the rest are returned as-is.  For example,
> > after copying an image from Firefox, I get this as the return value of
> > the above evaluation:
> > 
> >    [DataObject text/html HTML\ Format text/_moz_htmlinfo text/_moz_htmlcontext application/x-moz-file-promise-url application/x-moz-file-promise-dest-filename FILE_NAMES Preferred\ DropEffect application/x-moz-nativeimage DIB Ole\ Private\ Data BITMAP nil]
> > 
> > There's no image/* here, only DIB and BITMAP (which correspond to
> > CF_DIB and CF_BITMAP clipboard formats).  There are also a lot of
> > text/* formats, but they are all non-standard, except, perhaps,
> > text/html.  Do you have ideas how to select the proper format and how
> > to yank the data?
> 
> > What do the x/special-* formats correspond to on Windows?
> 
> We would convert the BITMAP format to image/png

But BITMAP is not PNG, AFAIU.  Moreover, with some images, when I copy
them in a Web browser, I see "PNG" in the targets vector reported by
gui-get-selection.  So I think we need to understand what exactly we
get with each format before we decide on the mapping.

As another data point. text/html seems to be Firefox-specific thing;
the standard Windows name for this is "HTML Format" (with the embedded
space).

> and FILE_NAMES to
> x-special/gnome-copied-files, to be compatible with what org-mode does 
> now. The offer to yank-media would then be text/html, image/png, and 
> x-special/gnome-copied-files, ignoring the rest of formats.

I don't like the Gnome-specific name x-special/gnome-copied-files.
I'd rather we produced a more generic name, and then ask the Org
developers to add support for it.

What about other kinds of media, like audio and video data?  Is that
supported, and if so, can we include that in some way?

Message #34 received at 71909 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Visuwesh <visuweshm <at> gmail.com>
Cc: cpardo <at> imayhem.com, 71909 <at> debbugs.gnu.org
Subject: Re: bug#71909: 30.0.60;
Date: Sun, 06 Oct 2024 14:50:49 +0300

> From: Visuwesh <visuweshm <at> gmail.com>
> Cc: Cecilio Pardo <cpardo <at> imayhem.com>,  71909 <at> debbugs.gnu.org
> Date: Sun, 06 Oct 2024 16:12:03 +0530
> 
> What happens when you copy text from, say, MS Office with formatting
> applied to it (bold, italic, whatever)?  The same with MS Office Excel.
> I was thinking of eventually™ writing handlers for LibreOffice when
> copying over table cells for org-mode.

That requires Emacs to know about Rich Text, and to be able to convert
that to Emacs faces.

> When copying rich text from LibreOffice's MS Word equivalent,
> yank-media-types reports:
> 
>     Possible completions are:
>     primary:text/html
>     clipboard:application/x-openoffice-link;windows_formatname="Link"
>     clipboard:application/x-openoffice-embed-source-xml;windows_formatname="Star Embed Source (XML)"
>     clipboard:TIMESTAMP
>     primary:STRING
>     primary:TEXT
>     primary:TIMESTAMP
>     primary:UTF8_STRING
>     primary:application/x-openoffice-embed-source-xml;windows_formatname="Star Embed Source (XML)"
>     primary:application/x-openoffice-objectdescriptor-xml;windows_formatname="Star Object Descriptor (XML)";classname="8BC6B165-B1B2-4EDD-aa47-dae2ee689dd6";typename="LibreOffice 24.2 Text Document";displayname="file:///home/viz/tmp/User_Manual.docx";viewaspect="1";width="17000";height="3000";posx="0";posy="0"
>     primary:text/plain
>     primary:text/plain;charset=utf-16
>     primary:text/plain;charset=utf-8
>     primary:text/richtext
>     primary:text/rtf

It is similar with Word on Windows, but the names of the formats are
different.

Also, if "primary:" means this is available in the PRIMARY selection,
then we are only talking about CLIPBOARD.  Try

  M-: (gui-get-selection 'CLIPBOARD 'TARGETS) RET

instead.

> where text/html is the most useful.

no, the most useful is Rich Text, but Emacs cannot yet yank that.

> When I copy a few table cells from LibreOffice's MS Excel equivalent, it
> reports:
> 
>     Possible completions are:
>     clipboard:application/x-openoffice-link;windows_formatname="Link"
>     clipboard:application/x-openoffice-embed-source-xml;windows_formatname="Star Embed Source (XML)"
>     clipboard:STRING
>     clipboard:TEXT
>     clipboard:TIMESTAMP
>     clipboard:UTF8_STRING
>     clipboard:application/x-libreoffice-tsvc
>     clipboard:application/x-openoffice-bitmap;windows_formatname="Bitmap"
>     clipboard:application/x-openoffice-dif;windows_formatname="DIF"
>     clipboard:application/x-openoffice-emf;windows_formatname="Image EMF"
>     clipboard:application/x-openoffice-gdimetafile;windows_formatname="GDIMetaFile"
>     clipboard:application/x-openoffice-objectdescriptor-xml;windows_formatname="Star Object Descriptor (XML)";classname="47BBB4CB-CE4C-4E80-a591-42d9ae74950f";typename="LibreOffice 24.2 Spreadsheet";displayname="file:///home/viz/doc/uni/pincer/convergence_for_Mn-1.ods";viewaspect="1";width="15846";height="4065";posx="0";posy="0"
>     clipboard:application/x-openoffice-sylk;windows_formatname="Sylk"
>     clipboard:application/x-openoffice-wmf;windows_formatname="Image WMF"
>     clipboard:image/bmp
>     clipboard:image/png
>     clipboard:text/html
>     clipboard:text/plain
>     clipboard:text/plain;charset=utf-16
>     clipboard:text/plain;charset=utf-8
>     clipboard:text/richtext
>     clipboard:text/rtf
>     primary:CLASS
>     primary:COMPOUND_TEXT
>     primary:HOST_NAME
>     primary:LENGTH
>     primary:NAME
>     primary:OWNER_OS
>     primary:STRING
>     primary:TEXT
>     primary:TIMESTAMP
>     primary:USER
>     primary:UTF8_STRING
>     primary:text/plain
>     primary:text/plain;charset=utf-8
> 
> image/png is, well, an image of the copied cells, and text/html has a
> (an?) HTML table.

On Windows, I see CSV, which I think is more useful (maybe tsvc above
is something similar).  You definitely do NOT want an image in this
case.

Message #37 received at 71909 <at> debbugs.gnu.org (full text, mbox):

From: Visuwesh <visuweshm <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: cpardo <at> imayhem.com, 71909 <at> debbugs.gnu.org
Subject: Re: bug#71909: 30.0.60;
Date: Sun, 06 Oct 2024 17:45:51 +0530

[ஞாயிறு அக்டோபர் 06, 2024] Eli Zaretskii wrote:

>> From: Visuwesh <visuweshm <at> gmail.com>
>> Cc: Cecilio Pardo <cpardo <at> imayhem.com>,  71909 <at> debbugs.gnu.org
>> Date: Sun, 06 Oct 2024 16:12:03 +0530
>> 
>> What happens when you copy text from, say, MS Office with formatting
>> applied to it (bold, italic, whatever)?  The same with MS Office Excel.
>> I was thinking of eventually™ writing handlers for LibreOffice when
>> copying over table cells for org-mode.
>
> That requires Emacs to know about Rich Text, and to be able to convert
> that to Emacs faces.

Which I hope someone will eventually do something about.  When
yank-media was first mentioned among org-mode users, one of the first
question was "Can it paste text copied from the browser in org-mode
format?" (i.e., convert bold text to *bold text*)

>> When copying rich text from LibreOffice's MS Word equivalent,
>> yank-media-types reports:
>> 
>>     Possible completions are:
>>     primary:text/html
>>     clipboard:application/x-openoffice-link;windows_formatname="Link"
>>     clipboard:application/x-openoffice-embed-source-xml;windows_formatname="Star Embed Source (XML)"
>>     clipboard:TIMESTAMP
>>[...]
> It is similar with Word on Windows, but the names of the formats are
> different.
>
> Also, if "primary:" means this is available in the PRIMARY selection,
> then we are only talking about CLIPBOARD.  

Yes, it means the PRIMARY selection.  For some reason, yank-media also
seems to consider the PRIMARY selection?  When I did M-x yank-media RET
in a html-mode buffer, it pasted the above text/html data.

> Try
>
>   M-: (gui-get-selection 'CLIPBOARD 'TARGETS) RET
>
> instead.
>
>> where text/html is the most useful.
>
> no, the most useful is Rich Text, but Emacs cannot yet yank that.

Possibly.  But we could at least "hijack" shr to convert text/html to
string with text properties on it, or make it insert markup elements.
I've done the later as a personal hack and it works fairly well.

>> When I copy a few table cells from LibreOffice's MS Excel equivalent, it
>> reports:
>> 
>>     Possible completions are:
>> [...]
>> image/png is, well, an image of the copied cells, and text/html has a
>> (an?) HTML table.
>
> On Windows, I see CSV, which I think is more useful (maybe tsvc above
> is something similar).  

You are right.  It pasted a TSV formatted text.  I missed it in the long
list of items.

> You definitely do NOT want an image in this case.

Definitely not.  I simply found it amusing that LibreOffice offered it
as a potential candidate.

Message #40 received at 71909 <at> debbugs.gnu.org (full text, mbox):

From: Cecilio Pardo <cpardo <at> imayhem.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 71909 <at> debbugs.gnu.org
Subject: Re: bug#71909: 30.0.60;
Date: Mon, 7 Oct 2024 12:24:01 +0200

On 06/10/2024 7:59, Eli Zaretskii wrote:

> But BITMAP is not PNG, AFAIU.  Moreover, with some images, when I copy
> them in a Web browser, I see "PNG" in the targets vector reported by
> gui-get-selection.  So I think we need to understand what exactly we
> get with each format before we decide on the mapping.

The standard bitmap formats for the clipboard (CF_BITMAP, CF_DIB, 
CF_DIBV5) are image data specific to windows, not an image format for 
saving to file.  We need to convert it to an image format, with a 
mime/type.  PNG or any other, even multiple ones.

GIMP on ubuntu for example does this when you copy a section of image:

[TIMESTAMP TARGETS MULTIPLE SAVE_TARGETS image/png image/bmp image/x-bmp 
image/x-MS-bmp image/x-icon image/x-ico image/x-win-bitmap 
image/vnd.microsoft.icon ...]

On windows it does this:

[PNG DIB BITMAP DIBV5]

And the Paint program that comes with Windows 11:

[DataObject Embed\ Source Native OwnerLink Object\ Descriptor METAFILE 
DIB PNG image/png Ole\ Private\ Data ENHMETAFILE BITMAP ...]

I didn't expect the PNG, image/png formats.  I suppose they are the same 
image as the DIB/BITMAP.  It seems programs are already doing the 
conversion.  I don't know the details yet, I'm on it.

So at least for images it seems most times we will have a well-known 
format.  If not (BITMAP,DIV), then we can do the PNG conversion.

> As another data point. text/html seems to be Firefox-specific thing;
> the standard Windows name for this is "HTML Format" (with the embedded
> space).

It may be interesting to handle some of this specific formats, from 
Firefox, or OpenOffice as discussed on another thread.  We will have to 
detect them somehow and decide what to do for each case.

> I don't like the Gnome-specific name x-special/gnome-copied-files.
> I'd rather we produced a more generic name, and then ask the Org
> developers to add support for it.

Of course.

> What about other kinds of media, like audio and video data?  Is that
> supported, and if so, can we include that in some way?

In standard formats there is CF_RIFF and CF_WAVE.  Also programas may 
insert a file format (as they do with PNGS), but I haven't found any 
example yet. In any case, we can do the same as with images.

Message #43 received at 71909 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Cecilio Pardo <cpardo <at> imayhem.com>
Cc: 71909 <at> debbugs.gnu.org
Subject: Re: bug#71909: 30.0.60;
Date: Mon, 07 Oct 2024 14:58:28 +0300

> Date: Mon, 7 Oct 2024 12:24:01 +0200
> Cc: 71909 <at> debbugs.gnu.org
> From: Cecilio Pardo <cpardo <at> imayhem.com>
> 
> On 06/10/2024 7:59, Eli Zaretskii wrote:
> 
> > But BITMAP is not PNG, AFAIU.  Moreover, with some images, when I copy
> > them in a Web browser, I see "PNG" in the targets vector reported by
> > gui-get-selection.  So I think we need to understand what exactly we
> > get with each format before we decide on the mapping.
> 
> The standard bitmap formats for the clipboard (CF_BITMAP, CF_DIB, 
> CF_DIBV5) are image data specific to windows, not an image format for 
> saving to file.  We need to convert it to an image format, with a 
> mime/type.  PNG or any other, even multiple ones.

Isn't CF_BITMAP format indicate the data to which we convert images on
Windows in the w32-specific portions of image.c?  Or maybe it's a BMP
data (which we can already display, see w32image.c)?  If so, then
yanking images into an Emacs buffer could simply use the data instead
of converting to PNG, then back to bitmap.

> GIMP on ubuntu for example does this when you copy a section of image:
> 
> [TIMESTAMP TARGETS MULTIPLE SAVE_TARGETS image/png image/bmp image/x-bmp 
> image/x-MS-bmp image/x-icon image/x-ico image/x-win-bitmap 
> image/vnd.microsoft.icon ...]
> 
> On windows it does this:
> 
> [PNG DIB BITMAP DIBV5]
> 
> And the Paint program that comes with Windows 11:
> 
> [DataObject Embed\ Source Native OwnerLink Object\ Descriptor METAFILE 
> DIB PNG image/png Ole\ Private\ Data ENHMETAFILE BITMAP ...]
> 
> I didn't expect the PNG, image/png formats.  I suppose they are the same 
> image as the DIB/BITMAP.

I'd rather expect them to be in PNG format.

> > What about other kinds of media, like audio and video data?  Is that
> > supported, and if so, can we include that in some way?
> 
> In standard formats there is CF_RIFF and CF_WAVE.  Also programas may 
> insert a file format (as they do with PNGS), but I haven't found any 
> example yet. In any case, we can do the same as with images.

If CF_WAVE are the same data as in *.wav files, then we should be able
to invoke play-sound in some way.

Message #46 received at 71909 <at> debbugs.gnu.org (full text, mbox):

From: Cecilio Pardo <cpardo <at> imayhem.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 71909 <at> debbugs.gnu.org
Subject: Re: bug#71909: 30.0.60;
Date: Wed, 9 Oct 2024 14:52:57 +0200

On 07/10/2024 13:58, Eli Zaretskii wrote:

> Isn't CF_BITMAP format indicate the data to which we convert images on
> Windows in the w32-specific portions of image.c?  Or maybe it's a BMP
> data (which we can already display, see w32image.c)?  If so, then
> yanking images into an Emacs buffer could simply use the data instead
> of converting to PNG, then back to bitmap.

But how would lisp programs register for receiving that?
yank-media-handler asks for mime types.

>> I didn't expect the PNG, image/png formats.  I suppose they are the same
>> image as the DIB/BITMAP.
> 
> I'd rather expect them to be in PNG format.

Yes, the same pixels, but in PNG format.

>>> What about other kinds of media, like audio and video data?  Is that
>>> supported, and if so, can we include that in some way?
>>
>> In standard formats there is CF_RIFF and CF_WAVE.  Also programas may
>> insert a file format (as they do with PNGS), but I haven't found any
>> example yet. In any case, we can do the same as with images.
> 
> If CF_WAVE are the same data as in *.wav files, then we should be able
> to invoke play-sound in some way.

But again, lisp programas need to register for a mime type, and then act 
on the data as they require.

Message #49 received at 71909 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Cecilio Pardo <cpardo <at> imayhem.com>
Cc: 71909 <at> debbugs.gnu.org
Subject: Re: bug#71909: 30.0.60;
Date: Wed, 09 Oct 2024 16:40:07 +0300

> Date: Wed, 9 Oct 2024 14:52:57 +0200
> Cc: 71909 <at> debbugs.gnu.org
> From: Cecilio Pardo <cpardo <at> imayhem.com>
> 
> On 07/10/2024 13:58, Eli Zaretskii wrote:
> 
> > Isn't CF_BITMAP format indicate the data to which we convert images on
> > Windows in the w32-specific portions of image.c?  Or maybe it's a BMP
> > data (which we can already display, see w32image.c)?  If so, then
> > yanking images into an Emacs buffer could simply use the data instead
> > of converting to PNG, then back to bitmap.
> 
> But how would lisp programs register for receiving that?
> yank-media-handler asks for mime types.

I believe the MIME type is image/bmp.

> > If CF_WAVE are the same data as in *.wav files, then we should be able
> > to invoke play-sound in some way.
> 
> But again, lisp programas need to register for a mime type, and then act 
> on the data as they require.

That's audio/wav, I believe.

Message #52 received at 71909 <at> debbugs.gnu.org (full text, mbox):

From: Cecilio Pardo <cpardo <at> imayhem.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 71909 <at> debbugs.gnu.org
Subject: Re: bug#71909: 30.0.60;
Date: Thu, 10 Oct 2024 12:04:31 +0200

On 05/10/2024 14:33, Eli Zaretskii wrote:
>> Date: Sat, 5 Oct 2024 14:28:35 +0200
>> From: Cecilio Pardo <cpardo <at> imayhem.com>
>>
>>
>> I'll be working on this, if no one else is.
> 
> Thanks in advance.
> 
> Btw, if you are looking for significant enhancements to Emacs on
> Windows, then support for color fonts (which needs to use Direct2D,
> AFAIU) will be greatly appreciated.

Is there an open bug about this, or should I open a new one?

Message #55 received at 71909 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Cecilio Pardo <cpardo <at> imayhem.com>
Cc: 71909 <at> debbugs.gnu.org
Subject: Re: bug#71909: 30.0.60;
Date: Thu, 10 Oct 2024 13:49:54 +0300

> Date: Thu, 10 Oct 2024 12:04:31 +0200
> Cc: 71909 <at> debbugs.gnu.org
> From: Cecilio Pardo <cpardo <at> imayhem.com>
> 
> On 05/10/2024 14:33, Eli Zaretskii wrote:
> >> Date: Sat, 5 Oct 2024 14:28:35 +0200
> >> From: Cecilio Pardo <cpardo <at> imayhem.com>
> >>
> > Btw, if you are looking for significant enhancements to Emacs on
> > Windows, then support for color fonts (which needs to use Direct2D,
> > AFAIU) will be greatly appreciated.
> 
> Is there an open bug about this, or should I open a new one?

I don't think we have a bug open for this.

Message #58 received at 71909 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> posteo.net>
To: Visuwesh <visuweshm <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 71909 <at> debbugs.gnu.org, cpardo <at> imayhem.com
Subject: Re: bug#71909: 30.0.60;
Date: Sun, 20 Oct 2024 13:09:01 +0000

Visuwesh <visuweshm <at> gmail.com> writes:

>>> where text/html is the most useful.
>>
>> no, the most useful is Rich Text, but Emacs cannot yet yank that.
>
> Possibly.  But we could at least "hijack" shr to convert text/html to
> string with text properties on it, or make it insert markup elements.
> I've done the later as a personal hack and it works fairly well.

May we utilize tree-sitter?
Having an AST, it should not be too hard to convert it into something
Emacs can understand.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Message #61 received at 71909 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: cpardo <at> imayhem.com, 71909 <at> debbugs.gnu.org, visuweshm <at> gmail.com
Subject: Re: bug#71909: 30.0.60;
Date: Sun, 20 Oct 2024 16:51:34 +0300

> From: Ihor Radchenko <yantar92 <at> posteo.net>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, cpardo <at> imayhem.com, 71909 <at> debbugs.gnu.org
> Date: Sun, 20 Oct 2024 13:09:01 +0000
> 
> Visuwesh <visuweshm <at> gmail.com> writes:
> 
> >>> where text/html is the most useful.
> >>
> >> no, the most useful is Rich Text, but Emacs cannot yet yank that.
> >
> > Possibly.  But we could at least "hijack" shr to convert text/html to
> > string with text properties on it, or make it insert markup elements.
> > I've done the later as a personal hack and it works fairly well.
> 
> May we utilize tree-sitter?
> Having an AST, it should not be too hard to convert it into something
> Emacs can understand.

You mean, someone has written a tree-sitter grammar for Rich Text?

If not, what do you mean by "utilize tree-sitter" in this context?

Message #64 received at 71909 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> posteo.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: cpardo <at> imayhem.com, 71909 <at> debbugs.gnu.org, visuweshm <at> gmail.com
Subject: Re: bug#71909: 30.0.60;
Date: Sun, 20 Oct 2024 13:59:47 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> May we utilize tree-sitter?
>> Having an AST, it should not be too hard to convert it into something
>> Emacs can understand.
>
> You mean, someone has written a tree-sitter grammar for Rich Text?

Yes. I did not check in details, but I did quick search before writing
my email and arrived at https://github.com/GoodNotes/tree-sitter-rtf

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Message #67 received at 71909 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: cpardo <at> imayhem.com, 71909 <at> debbugs.gnu.org, visuweshm <at> gmail.com
Subject: Re: bug#71909: 30.0.60;
Date: Sun, 20 Oct 2024 17:22:43 +0300

> From: Ihor Radchenko <yantar92 <at> posteo.net>
> Cc: visuweshm <at> gmail.com, cpardo <at> imayhem.com, 71909 <at> debbugs.gnu.org
> Date: Sun, 20 Oct 2024 13:59:47 +0000
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> May we utilize tree-sitter?
> >> Having an AST, it should not be too hard to convert it into something
> >> Emacs can understand.
> >
> > You mean, someone has written a tree-sitter grammar for Rich Text?
> 
> Yes. I did not check in details, but I did quick search before writing
> my email and arrived at https://github.com/GoodNotes/tree-sitter-rtf

Someone will need to generate the parser from that, before people can
compile and use the grammar library.

Message #70 received at 71909 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> posteo.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: cpardo <at> imayhem.com, 71909 <at> debbugs.gnu.org, visuweshm <at> gmail.com
Subject: Re: bug#71909: 30.0.60;
Date: Sun, 20 Oct 2024 15:02:18 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> > You mean, someone has written a tree-sitter grammar for Rich Text?
>> 
>> Yes. I did not check in details, but I did quick search before writing
>> my email and arrived at https://github.com/GoodNotes/tree-sitter-rtf
>
> Someone will need to generate the parser from that, before people can
> compile and use the grammar library.

What is the problem generating parser library from source code?
The source code is there. Generating is simply yarn generate.


-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Message #73 received at 71909 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: cpardo <at> imayhem.com, 71909 <at> debbugs.gnu.org, visuweshm <at> gmail.com
Subject: Re: bug#71909: 30.0.60;
Date: Sun, 20 Oct 2024 18:34:04 +0300

> From: Ihor Radchenko <yantar92 <at> posteo.net>
> Cc: visuweshm <at> gmail.com, cpardo <at> imayhem.com, 71909 <at> debbugs.gnu.org
> Date: Sun, 20 Oct 2024 15:02:18 +0000
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> > You mean, someone has written a tree-sitter grammar for Rich Text?
> >> 
> >> Yes. I did not check in details, but I did quick search before writing
> >> my email and arrived at https://github.com/GoodNotes/tree-sitter-rtf
> >
> > Someone will need to generate the parser from that, before people can
> > compile and use the grammar library.
> 
> What is the problem generating parser library from source code?
> The source code is there. Generating is simply yarn generate.

We want to assume that everyone has yarn (and Node.js)?
treesit-install-language-grammar assumes the library's Git repository
includes code in C or C++.

All the other grammar libraries include the parser (and scanner, where
needed) in the Git repository, so I wonder why this one doesn't.

Message #76 received at 71909 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> posteo.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: cpardo <at> imayhem.com, 71909 <at> debbugs.gnu.org, visuweshm <at> gmail.com
Subject: Re: bug#71909: 30.0.60;
Date: Sun, 20 Oct 2024 15:57:48 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> What is the problem generating parser library from source code?
>> The source code is there. Generating is simply yarn generate.
>
> We want to assume that everyone has yarn (and Node.js)?
> treesit-install-language-grammar assumes the library's Git repository
> includes code in C or C++.

> All the other grammar libraries include the parser (and scanner, where
> needed) in the Git repository, so I wonder why this one doesn't.

I see. It looks like a small problem. But one can set a CI pipeline to
compile the grammar automatically in a separate repository.

AFAIU, there are no license obstacles for doing this.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Message #79 received at 71909 <at> debbugs.gnu.org (full text, mbox):

From: Cecilio Pardo <cpardo <at> imayhem.com>
To: Ihor Radchenko <yantar92 <at> posteo.net>, Visuwesh <visuweshm <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 71909 <at> debbugs.gnu.org
Subject: Re: bug#71909: 30.0.60;
Date: Sun, 20 Oct 2024 19:16:03 +0200

On 20/10/2024 15:09, Ihor Radchenko wrote:
> Visuwesh <visuweshm <at> gmail.com> writes:
> 
>>>> where text/html is the most useful.
>>>
>>> no, the most useful is Rich Text, but Emacs cannot yet yank that.
>>
>> Possibly.  But we could at least "hijack" shr to convert text/html to
>> string with text properties on it, or make it insert markup elements.
>> I've done the later as a personal hack and it works fairly well.
> 
> May we utilize tree-sitter?
> Having an AST, it should not be too hard to convert it into something
> Emacs can understand.

I had planned to try to use UnRTF for this.

https://www.gnu.org/software/unrtf/

It's a GNU package, and despite being old and (I think) unmaintained, it 
is used by many wrappers for different languages, so it probably works 
well, though I haven't tested it myself yet.

Has it been already tried for emacs?

If not, which approach (tree-sitter, unrtf) would be more promising?

Message #82 received at 71909 <at> debbugs.gnu.org (full text, mbox):

From: Visuwesh <visuweshm <at> gmail.com>
To: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 71909 <at> debbugs.gnu.org, cpardo <at> imayhem.com
Subject: Re: bug#71909: 30.0.60;
Date: Sun, 20 Oct 2024 23:20:50 +0530

[ஞாயிறு அக்டோபர் 20, 2024] Ihor Radchenko wrote:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> What is the problem generating parser library from source code?
>>> The source code is there. Generating is simply yarn generate.
>>
>> We want to assume that everyone has yarn (and Node.js)?
>> treesit-install-language-grammar assumes the library's Git repository
>> includes code in C or C++.
>
>> All the other grammar libraries include the parser (and scanner, where
>> needed) in the Git repository, so I wonder why this one doesn't.
>
> I see. It looks like a small problem. But one can set a CI pipeline to
> compile the grammar automatically in a separate repository.
>
> AFAIU, there are no license obstacles for doing this.

Can we not ask the author of the library to provide the C/C++ files in
the repo?

Message #85 received at 71909 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Cecilio Pardo <cpardo <at> imayhem.com>
Cc: yantar92 <at> posteo.net, 71909 <at> debbugs.gnu.org, visuweshm <at> gmail.com
Subject: Re: bug#71909: 30.0.60;
Date: Sun, 20 Oct 2024 20:58:00 +0300

> Date: Sun, 20 Oct 2024 19:16:03 +0200
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 71909 <at> debbugs.gnu.org
> From: Cecilio Pardo <cpardo <at> imayhem.com>
> 
> I had planned to try to use UnRTF for this.
> 
> https://www.gnu.org/software/unrtf/
> 
> It's a GNU package, and despite being old and (I think) unmaintained, it 
> is used by many wrappers for different languages, so it probably works 
> well, though I haven't tested it myself yet.
> 
> Has it been already tried for emacs?

I don't think so.

> If not, which approach (tree-sitter, unrtf) would be more promising?

It depends on which one covers the RTF spec better, I think.  All the
rest being equal, I think tree-sitter is more promising, because it
will definitely be faster.  OTOH, an Emacs-specific downside of using
tree-sitter is that we don't have any experience using TS
structure-related information (sectioning, tables, numbered lists,
etc.) in Emacs, we only use TS for faces and indentation.  UnRTF
converts to HTML, and we already know how to use this stuff when
expressed in HTML.

Message #88 received at 71909 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Visuwesh <visuweshm <at> gmail.com>
Cc: yantar92 <at> posteo.net, 71909 <at> debbugs.gnu.org, cpardo <at> imayhem.com
Subject: Re: bug#71909: 30.0.60;
Date: Sun, 20 Oct 2024 20:59:06 +0300

> From: Visuwesh <visuweshm <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  cpardo <at> imayhem.com,  71909 <at> debbugs.gnu.org
> Date: Sun, 20 Oct 2024 23:20:50 +0530
> 
> [ஞாயிறு அக்டோபர் 20, 2024] Ihor Radchenko wrote:
> 
> > Eli Zaretskii <eliz <at> gnu.org> writes:
> >
> >>> What is the problem generating parser library from source code?
> >>> The source code is there. Generating is simply yarn generate.
> >>
> >> We want to assume that everyone has yarn (and Node.js)?
> >> treesit-install-language-grammar assumes the library's Git repository
> >> includes code in C or C++.
> >
> >> All the other grammar libraries include the parser (and scanner, where
> >> needed) in the Git repository, so I wonder why this one doesn't.
> >
> > I see. It looks like a small problem. But one can set a CI pipeline to
> > compile the grammar automatically in a separate repository.
> >
> > AFAIU, there are no license obstacles for doing this.
> 
> Can we not ask the author of the library to provide the C/C++ files in
> the repo?

It cannot hurt.

Message #91 received at 71909 <at> debbugs.gnu.org (full text, mbox):

From: Cecilio Pardo <cpardo <at> imayhem.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 71909 <at> debbugs.gnu.org
Subject: Re: bug#71909: 30.0.60; yank-media on MS-Windows
Date: Thu, 24 Oct 2024 01:13:49 +0200

Getting back to this, I have been checking what some programs (a couple
of nonfree ones) provide on the clipboard for different media types.

GIMP           | Copy pixels           | PNG
LibreOffice    | Copy vectorial object | PNG, GDIMetafile
LibreOffice    | Copy embedded image   | PNG
LibreOffice    | Copy text             | RTF, HTML, ODT
LibreOffice    | Copy equation         | RTF
LibreOffice    | Copy Calc cells       | PNG, RTF, HTML, GDIMetafile
Firefox        | Copy Image            | DIBV5
Firefox        | Copy Text             | HTML, RTF
Krita          | Copy pixels           | PNG
Inkscape       | Copy vector           | SVG, PNG, PDF, Postscript
Windows Paint  | Copy pixels           | PNG
Acrobat Reader | Copy text             | RTF

They offer more formats, but in many cases they are not really there 
(the yank-media code knows about this, and in fact checks every type to 
purge the empty ones from list), or are propietary.

So I think we should stick to these:

- Rename PNG to image/png, so the emacs programs find it. If there are 
other image formats with mime spec, yank-media will let the user choose. 
For example, krita offers a huge amount of formats, as mime.

- If no PNG is offered, but DIBV5 is, like Firefox, convert the pixel 
data to a PNG file, and offer it as image/png. We don't loose anything 
converting the BMP to PNG, and the programs that use yank-media for 
images (message-mode, org-mode) need a file, not an in-memory image 
object. And PNG is a much better format.

- GDIMetafile would be ideally converted to SVG. Offering the metafile 
as it is makes little sense in my opinion. It is not a very used format.

- Text as HTML should be offered as text/html, for the use of html 
editing modes.

- Rtf text should be offered also to org-mode, adding a new yank handler 
to convert rtf format to org format. I am working on that. We could also 
provide it to enriched-mode, but it could use very few properties of the 
text. Anyway, this is not a Windows issue, and it still a little far away.

Message #94 received at 71909 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Cecilio Pardo <cpardo <at> imayhem.com>
Cc: 71909 <at> debbugs.gnu.org
Subject: Re: bug#71909: 30.0.60; yank-media on MS-Windows
Date: Thu, 24 Oct 2024 10:18:08 +0300

> Date: Thu, 24 Oct 2024 01:13:49 +0200
> Cc: 71909 <at> debbugs.gnu.org
> From: Cecilio Pardo <cpardo <at> imayhem.com>
> 
> - Rename PNG to image/png, so the emacs programs find it. If there are 
> other image formats with mime spec, yank-media will let the user choose. 
> For example, krita offers a huge amount of formats, as mime.
> 
> - If no PNG is offered, but DIBV5 is, like Firefox, convert the pixel 
> data to a PNG file, and offer it as image/png. We don't loose anything 
> converting the BMP to PNG, and the programs that use yank-media for 
> images (message-mode, org-mode) need a file, not an in-memory image 
> object. And PNG is a much better format.

I'm not sure I follow: isn't yank-media about yanking the image into
the current buffer?  If so, why is having a file important, let alone
necessary?

> - GDIMetafile would be ideally converted to SVG. Offering the metafile 
> as it is makes little sense in my opinion. It is not a very used format.

Will we support yanking from a spreadsheet?  If so, with what format?

> - Text as HTML should be offered as text/html, for the use of html 
> editing modes.
> 
> - Rtf text should be offered also to org-mode, adding a new yank handler 
> to convert rtf format to org format. I am working on that. We could also 
> provide it to enriched-mode, but it could use very few properties of the 
> text. Anyway, this is not a Windows issue, and it still a little far away.

Where we have both RTF and HTML, should we perhaps use HTML and pass
it through shr, to produce text with faces, rather than raw HTML?
Once RTF handler exists, we could use that instead, but having it
rendered via HTML might be a useful option anyway.

Anyway, all in all, this sounds like a good plan, thanks.

Message #97 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Cecilio Pardo <cpardo <at> imayhem.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#71909: 30.0.60; yank-media on MS-Windows
Date: Thu, 24 Oct 2024 10:39:13 +0200

On 24/10/2024 9:18, Eli Zaretskii wrote:

>> - If no PNG is offered, but DIBV5 is, like Firefox, convert the pixel
>> data to a PNG file, and offer it as image/png. We don't loose anything
>> converting the BMP to PNG, and the programs that use yank-media for
>> images (message-mode, org-mode) need a file, not an in-memory image
>> object. And PNG is a much better format.
> 
> I'm not sure I follow: isn't yank-media about yanking the image into
> the current buffer?  If so, why is having a file important, let alone
> necessary?

I mean they need data in the format that would go into a file, PNG, BMP, 
etc. Not the kind of data that is a DIB. We could easily convert in to a 
BMP file, but, once we need to manipulate it, better to give a PNG.

org-mode stores the yanked images as attachments, saving files. 
message-mode stores the images in the message like this:

<#part type="image/png" disposition=inline data-encoding=base64 raw=t>
iVBORw0KGgoAA...

That is, not a file in disk, but the data that would go into a PNG file.

>> - GDIMetafile would be ideally converted to SVG. Offering the metafile
>> as it is makes little sense in my opinion. It is not a very used format.
> 
> Will we support yanking from a spreadsheet?  If so, with what format?

Yes, LibreOffice offers them as RTF, with a table. Also in HTML. I'm 
hoping to convert RTF tables to org-mode tables.

> Where we have both RTF and HTML, should we perhaps use HTML and pass
> it through shr, to produce text with faces, rather than raw HTML?
> Once RTF handler exists, we could use that instead, but having it
> rendered via HTML might be a useful option anyway.

What mode could benefit from yanking propertized test?

Message #100 received at 71909 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Cecilio Pardo <cpardo <at> imayhem.com>
Cc: 71909 <at> debbugs.gnu.org
Subject: Re: bug#71909: 30.0.60; yank-media on MS-Windows
Date: Thu, 24 Oct 2024 12:38:49 +0300

> Date: Thu, 24 Oct 2024 10:39:13 +0200
> From: Cecilio Pardo <cpardo <at> imayhem.com>
> 
> On 24/10/2024 9:18, Eli Zaretskii wrote:
> 
> >> - If no PNG is offered, but DIBV5 is, like Firefox, convert the pixel
> >> data to a PNG file, and offer it as image/png. We don't loose anything
> >> converting the BMP to PNG, and the programs that use yank-media for
> >> images (message-mode, org-mode) need a file, not an in-memory image
> >> object. And PNG is a much better format.
> > 
> > I'm not sure I follow: isn't yank-media about yanking the image into
> > the current buffer?  If so, why is having a file important, let alone
> > necessary?
> 
> I mean they need data in the format that would go into a file, PNG, BMP, 
> etc. Not the kind of data that is a DIB. We could easily convert in to a 
> BMP file, but, once we need to manipulate it, better to give a PNG.

Maybe we need an image-save-as function, to save an image's data to a
file, then?  What you describe sounds like a separate requirement.

> org-mode stores the yanked images as attachments, saving files. 
> message-mode stores the images in the message like this:
> 
> <#part type="image/png" disposition=inline data-encoding=base64 raw=t>
> iVBORw0KGgoAA...
> 
> That is, not a file in disk, but the data that would go into a PNG file.

If a file is needed, writing the image data to a file will solve it
(and is a useful feature to have, regardless).

Does yank-media produce image files on GNU/Linux, when it yanks
images?

> > Where we have both RTF and HTML, should we perhaps use HTML and pass
> > it through shr, to produce text with faces, rather than raw HTML?
> > Once RTF handler exists, we could use that instead, but having it
> > rendered via HTML might be a useful option anyway.
> 
> What mode could benefit from yanking propertized test?

Any descendant of Text mode can use propertized text.  It doesn't
_have_ to be so, but it's possible, and I think we should offer that
if we can.

Message #103 received at 71909 <at> debbugs.gnu.org (full text, mbox):

From: Cecilio Pardo <cpardo <at> imayhem.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 71909 <at> debbugs.gnu.org
Subject: Re: bug#71909: 30.0.60; yank-media on MS-Windows
Date: Thu, 24 Oct 2024 12:43:29 +0200

On 24/10/2024 11:38, Eli Zaretskii wrote:
>> Date: Thu, 24 Oct 2024 10:39:13 +0200
>> From: Cecilio Pardo <cpardo <at> imayhem.com>
>>
>> On 24/10/2024 9:18, Eli Zaretskii wrote:
>>
>>> I'm not sure I follow: isn't yank-media about yanking the image into
>>> the current buffer?  If so, why is having a file important, let alone
>>> necessary?
>>
>> I mean they need data in the format that would go into a file, PNG, BMP,
>> etc. Not the kind of data that is a DIB. We could easily convert in to a
>> BMP file, but, once we need to manipulate it, better to give a PNG.
> 
> Maybe we need an image-save-as function, to save an image's data to a
> file, then?  What you describe sounds like a separate requirement.
> 
>> org-mode stores the yanked images as attachments, saving files.
>> message-mode stores the images in the message like this:
>>
>> <#part type="image/png" disposition=inline data-encoding=base64 raw=t>
>> iVBORw0KGgoAA...
>>
>> That is, not a file in disk, but the data that would go into a PNG file.
> 
> If a file is needed, writing the image data to a file will solve it
> (and is a useful feature to have, regardless).
> 
> Does yank-media produce image files on GNU/Linux, when it yanks
> images?
> 

No, yank-media calls a handler (lisp function) given by the current mode 
that receives raw data for the clipboard content. The content 
corresponds to some file format. The mode specifies which mime types it 
wants, and specify a handler for each one of them. If after invoking 
yank-media there is more that one format accepted by the mode, the user 
has to choose one.

Org-mode saves the files to disk, message-mode embeds them in the body 
of the message, other modes could do differently.

This behaviour is only for GNU/Linux (and other ports I guess), on 
Windows yank-media does nothing currently.

>>> Where we have both RTF and HTML, should we perhaps use HTML and pass
>>> it through shr, to produce text with faces, rather than raw HTML?
>>> Once RTF handler exists, we could use that instead, but having it
>>> rendered via HTML might be a useful option anyway.
>>
>> What mode could benefit from yanking propertized test?
> 
> Any descendant of Text mode can use propertized text.  It doesn't
> _have_ to be so, but it's possible, and I think we should offer that
> if we can.

Then we can make Text-mode add a media handler for html-text (and 
hopefully tich text later), and convert it into propertized text.

Message #106 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Cecilio Pardo <cpardo <at> imayhem.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#71909: 30.0.60;
Date: Mon, 28 Oct 2024 22:46:36 +0100

[Message part 1 (text/plain, inline)]

This patch adds support for yank-media on MS-Windows.  Media is handled
in some different ways:

- Clipboard data that is already named as a mime-type needs no work
  besides returning it. For example, Krita provides copied pixels as
  multiple image/xxxx types, and Firefox provides html as text/html.

- Other programs don't use mime types. We try to recognize some names
  and change then to mime types. For example, GIMP uses the name "PNG"
  for copied pixels. We change it to image/png. LibreOffice also uses
  "PNG" for images. It uses "HTML Format" for rich text and also for
  spreadsheet cells, and we change that to text/html.

- Finally, some programs supply image data in DIBV5 format. We offer
  it as image/png, and convert in on the fly when requested. Firefox
  does this when using "Copy image".

This are the tested media types:

- [X] GIMP copy pixels             -> image/png
- [X] LibreOffice vectorial object -> image/png
- [X] LibreOffice embedded image   -> image/png
- [X] LibreOffice rich text        -> text/html
- [X] LibreOffice Calc cells       -> text/html
- [X] Firefox copy image           -> image/png (also text/html as
                                      embedded image)
- [X] Firefox page text            -> text/html
- [X] Krita pixels                 -> image/png (and others)
- [X] InkScape                     -> image/svg+xml, image/png

Images can be yanked in at least org-mode, message-mode, html-mode.
HTML (text/html) can be yanked in at least html-mode.

SVG will not work until bug #74044 is fixed.

LibreOffice offers vectorial objects as Metafiles, that
could be converted to SVG. I may do that at some point.

This patch does NOT include the planned functionality to yank rich
text as propertized text, or to use RTF format as a source. Those are
not Windows-only.

It also includes a small fix in sgml-mode.el. It was mangling image
files because of Windows new lines.

The image conversion is done using GdiPlus functions, which are
already used on w32image.c, but are static. I have splitted this file
into .c and .h, to be able to reuse those definitions. The image
conversion requires that native image functions are activated.

Now I think this patch may have been splitted into 2 or 3 for review. 
Let me know if that would be better.

[0001-Add-support-for-yank-media-on-MS-Windows.patch (text/plain, attachment)]

Message #109 received at 71909 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Cecilio Pardo <cpardo <at> imayhem.com>
Cc: 71909 <at> debbugs.gnu.org
Subject: Re: bug#71909: 30.0.60;
Date: Tue, 29 Oct 2024 16:25:29 +0200

> Date: Mon, 28 Oct 2024 22:46:36 +0100
> From: Cecilio Pardo <cpardo <at> imayhem.com>
> 
> This patch adds support for yank-media on MS-Windows.  Media is handled
> in some different ways:
> 
> - Clipboard data that is already named as a mime-type needs no work
>    besides returning it. For example, Krita provides copied pixels as
>    multiple image/xxxx types, and Firefox provides html as text/html.
> 
> - Other programs don't use mime types. We try to recognize some names
>    and change then to mime types. For example, GIMP uses the name "PNG"
>    for copied pixels. We change it to image/png. LibreOffice also uses
>    "PNG" for images. It uses "HTML Format" for rich text and also for
>    spreadsheet cells, and we change that to text/html.
> 
> - Finally, some programs supply image data in DIBV5 format. We offer
>    it as image/png, and convert in on the fly when requested. Firefox
>    does this when using "Copy image".
> 
> This are the tested media types:
> 
> - [X] GIMP copy pixels             -> image/png
> - [X] LibreOffice vectorial object -> image/png
> - [X] LibreOffice embedded image   -> image/png
> - [X] LibreOffice rich text        -> text/html
> - [X] LibreOffice Calc cells       -> text/html
> - [X] Firefox copy image           -> image/png (also text/html as
>                                        embedded image)
> - [X] Firefox page text            -> text/html
> - [X] Krita pixels                 -> image/png (and others)
> - [X] InkScape                     -> image/svg+xml, image/png
> 
> Images can be yanked in at least org-mode, message-mode, html-mode.
> HTML (text/html) can be yanked in at least html-mode.
> 
> SVG will not work until bug #74044 is fixed.

Thanks.

> The image conversion is done using GdiPlus functions, which are
> already used on w32image.c, but are static. I have splitted this file
> into .c and .h, to be able to reuse those definitions. The image
> conversion requires that native image functions are activated.

What happens with yank-media if the user disables native image APIs?
Do we signal an error or is there some graceful degradation (like
using another MIME type)?

> Now I think this patch may have been splitted into 2 or 3 for review. 
> Let me know if that would be better.

I personally prefer a single patch.

> * lisp/term/w32-win.el (w32--selection-target-translations): New
> variable that holds the name translations for media tytpes.
> (w32--translate-selection-target): New function, translate the name of a
> media type.
> (w32--translate-reverse-selection-target): New function, Reverse
> translation.
> (w32--get-selection): Modified to translate target names when asked for
> targets, and retrieve media types when asked for them.
> * lisp/textmodes/sgml-mode.el (html-mode--image-yank-handler): Fixed the
> image save mechanism, that added line feed characters on MS-Windows,
> breaking binary formats.
> * src/w32image.c (gdiplus_init): Modified to fetch more functions fromm
> gdiplus.
> (get_encoder_clsid): renamed to w32_gdip_get_encoder_clsid and made
> nonstatic.
> * src/w32select.c (stdfmt_name): Made global, was function static.
> (convert_dibv5_to_png): New function to convert DIBV5 clipboard format
> to PNG.
> (get_clipboard_format_name): New function get the name of a format given
> its index.
> (Fw32__get_clipboard_data_media): New function, retrieves and convert
> media content.
> (syms_of_w32select): Export new lisp functions
> * src/w32gdiplus.h: New file, for definitions in w32image.c

Some of these lines are too long, please make sure they don't exceed
70 columns, preferably 63.

> +(defun w32--translate-reverse-selection-target(target)
> +  (let ((ret
> +         (append
> +          (cl-mapcar #'car
> +                     (cl-remove-if-not

This will load cl-seq in every w32 session, so let's not call cl-*
functions in preloaded files.

> +        ((eq type 'CLIPBOARD)
> +         (let* ((tmp-file (make-temp-file "emacs-clipboard"))
> +                (data-types (w32--translate-reverse-selection-target data-type))
> +                (data (w32--get-clipboard-data-media data-types tmp-file))
> +                (result (cond
> +                         ;; data is in the file
> +                         ((eq data t)
> +                          (with-temp-buffer
> +                            (set-buffer-multibyte nil)
> +                            (insert-file-contents-literally tmp-file)
> +                            (buffer-string)))
> +                         ;; data is in data var
> +                         ((stringp data) data)
> +                         ;; No data
> +                         (t nil))))
> +           (delete-file tmp-file)
> +           result))

This should use unwind-protect and/or condition-case, to make sure the
temporary file is deleted even if the user presses C-g or some code
signals an error.

> +DEFUN ("w32--get-clipboard-data-media", Fw32__get_clipboard_data_media,
> +       Sw32__get_clipboard_data_media, 2, 2, 0,
> +       doc: /* Gets media (not plain text) clipboard data in one of the given formats.
> +FORMATS is the list of formats.

This should say something about what can be put into FORMATS.

Also, "a list", not "the list".

> +TEMP-FILE-IN is the name of the file to store the data, that must be
> +created by the callee, and also deleted if required.
> +The passed file may be used or not, as indicated by the return value:

Isn't it easier and clearer to say "if the function returns t"?

> +Returns nil it there is no such format, or something failed.
> +If it returns a string, then that is the data (not necessarily textual).
> +If it returns 't, then the file contains the data.  */)
                 ^^
t, not 't

> +  (Lisp_Object formats, Lisp_Object temp_file_in)
> +{
> +  CHECK_CONS (formats);

CHECK_CONS or CHECK_LIST?

> +  char *temp_file = SSDATA (ENCODE_FILE (temp_file_in));

Every file name that we pass to C APIs must be run through
Fexpand_file_name, because each buffer in Emacs can have its own
default-directory.

> +      if (strcmp (name, "DIBV5") == 0)
> +	{
> +	  if (convert_dibv5_to_png (data, size, temp_file))
> +	    result = Qt;
> +	}
> +      else
> +	result = make_unibyte_string (data, size);

Why a unibyte string?  Is this always binary data or something?  If
this could be text (e.g., text/html), then a unibyte string is not the
best choice.

In any case, if the function must return a unibyte string in some
cases, that should be mentioned in the doc string, because callers
will otherwise not expect to get a unibyte string.  Also, where will
this unibyte string be decoded?

Finally, this needs some documentation: a NEWS item and some minimal
updates for the "Yanking Media" section of the ELisp manual (AFAICT,
it only needs to say that media can be yanked from the clipboard as
well as from a selection).

Message #112 received at 71909 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: cpardo <at> imayhem.com
Cc: 71909 <at> debbugs.gnu.org
Subject: Re: bug#71909: 30.0.60;
Date: Tue, 29 Oct 2024 16:55:15 +0200

> Cc: 71909 <at> debbugs.gnu.org
> Date: Tue, 29 Oct 2024 16:25:29 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> Finally, this needs some documentation: a NEWS item and some minimal
> updates for the "Yanking Media" section of the ELisp manual (AFAICT,
> it only needs to say that media can be yanked from the clipboard as
> well as from a selection).

And one more issue: I get a compilation error using MinGW because
CF_DIBV5 is only defined since Win2K, and MinGW compilation generally
uses the default value of _WIN32_WINNT, which is set for Windows 9X.
So I suggest the following addition to w32select.c to work around that
(defining a larger value of _WIN32_WINNT doesn't seem justified for
such a minor nit):

#include <config.h>
#include <windows.h>
#include <wingdi.h>
#include <wtypes.h>
#include <gdiplus.h>
#ifndef CF_DIBV5      <<<<<<<<<<<<<<<<<<<<<
# define CF_DIBV5 17  <<<<<<<<<<<<<<<<<<<<<
# undef CF_MAX        <<<<<<<<<<<<<<<<<<<<<
# define CF_MAX 18    <<<<<<<<<<<<<<<<<<<<<
#endif                <<<<<<<<<<<<<<<<<<<<<
#include "lisp.h"

Message #115 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Cecilio Pardo <cpardo <at> imayhem.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#71909: 30.0.60;
Date: Wed, 30 Oct 2024 10:05:08 +0100

>> The image conversion is done using GdiPlus functions, which are
>> already used on w32image.c, but are static. I have splitted this file
>> into .c and .h, to be able to reuse those definitions. The image
>> conversion requires that native image functions are activated.
> 
> What happens with yank-media if the user disables native image APIs?
> Do we signal an error or is there some graceful degradation (like
> using another MIME type)?

The ability to yank DIBV5 will be lost. If there is no alternative such 
as PNG or image/*, then yank can't be done.

> Why a unibyte string?  Is this always binary data or something?  If
> this could be text (e.g., text/html), then a unibyte string is not the
> best choice.

It can be binary, but not always.  Is unibyte ok for binary cases? I can 
treat text/* differently, and make exceptions for types like image/svg+xml.

> In any case, if the function must return a unibyte string in some
> cases, that should be mentioned in the doc string, because callers
> will otherwise not expect to get a unibyte string.  Also, where will
> this unibyte string be decoded?

In the binary case, is there any decoding to do?

Message #118 received at 71909 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Cecilio Pardo <cpardo <at> imayhem.com>
Cc: 71909 <at> debbugs.gnu.org
Subject: Re: bug#71909: 30.0.60;
Date: Wed, 30 Oct 2024 17:35:36 +0200

> Date: Wed, 30 Oct 2024 10:05:08 +0100
> From: Cecilio Pardo <cpardo <at> imayhem.com>
> 
> >> The image conversion is done using GdiPlus functions, which are
> >> already used on w32image.c, but are static. I have splitted this file
> >> into .c and .h, to be able to reuse those definitions. The image
> >> conversion requires that native image functions are activated.
> > 
> > What happens with yank-media if the user disables native image APIs?
> > Do we signal an error or is there some graceful degradation (like
> > using another MIME type)?
> 
> The ability to yank DIBV5 will be lost. If there is no alternative such 
> as PNG or image/*, then yank can't be done.

Is this because w32-use-native-image-API set to nil disables loading
of GDI+?  If so, we could load it even if w32-use-native-image-API is
nil, but just return false from w32_can_use_native_image_api.  This
would allow us to use the GDI+ functions needed for yanking, but not
those needed for image display.  Does this make sense?

> > Why a unibyte string?  Is this always binary data or something?  If
> > this could be text (e.g., text/html), then a unibyte string is not the
> > best choice.
> 
> It can be binary, but not always.  Is unibyte ok for binary cases?

Yes.  But we need to document that in the doc string.

> I can 
> treat text/* differently, and make exceptions for types like image/svg+xml.

That'd be much better.

> > In any case, if the function must return a unibyte string in some
> > cases, that should be mentioned in the doc string, because callers
> > will otherwise not expect to get a unibyte string.  Also, where will
> > this unibyte string be decoded?
> 
> In the binary case, is there any decoding to do?

No.

Message #121 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Cecilio Pardo <cpardo <at> imayhem.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#71909: 30.0.60;
Date: Wed, 30 Oct 2024 16:49:44 +0100

On 30/10/2024 16:35, Eli Zaretskii wrote:
>> The ability to yank DIBV5 will be lost. If there is no alternative such
>> as PNG or image/*, then yank can't be done.
> 
> Is this because w32-use-native-image-API set to nil disables loading
> of GDI+?  If so, we could load it even if w32-use-native-image-API is
> nil, but just return false from w32_can_use_native_image_api.  This
> would allow us to use the GDI+ functions needed for yanking, but not
> those needed for image display.  Does this make sense?

Yes, I'll do that.

>>> Why a unibyte string?  Is this always binary data or something?  If
>>> this could be text (e.g., text/html), then a unibyte string is not the
>>> best choice.
>>
>> It can be binary, but not always.  Is unibyte ok for binary cases?
> 
> Yes.  But we need to document that in the doc string.
> 
>> I can
>> treat text/* differently, and make exceptions for types like image/svg+xml.
> 
> That'd be much better.

Ok.

I'm on it.

Message #124 received at 71909 <at> debbugs.gnu.org (full text, mbox):

From: Cecilio Pardo <cpardo <at> imayhem.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 71909 <at> debbugs.gnu.org
Subject: Re: bug#71909: 30.0.60;
Date: Sat, 2 Nov 2024 01:23:11 +0100

[Message part 1 (text/plain, inline)]

Here is a new version, with the discussed corrections.

- Now the test for gdiplus is done calling w32_gdiplus_startup.
  Will use it if its available, even if native image functions
  are disabled.
- Don't use cl-seq.
- Use Fexpand_file_name on file name.
- Send unibyte string only for binary data.
- Use unwind-protect to ensure temp file is deleted.
- Fixed docs, changelog, NEWS and manual.

[0001-Add-support-for-yank-media-on-MS-Windows.patch (text/plain, attachment)]

Message #127 received at 71909 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Cecilio Pardo <cpardo <at> imayhem.com>
Cc: 71909 <at> debbugs.gnu.org
Subject: Re: bug#71909: 30.0.60;
Date: Sat, 02 Nov 2024 12:44:32 +0200

> Date: Sat, 2 Nov 2024 01:23:11 +0100
> Cc: 71909 <at> debbugs.gnu.org
> From: Cecilio Pardo <cpardo <at> imayhem.com>
> 
> Here is a new version, with the discussed corrections.
> 
> - Now the test for gdiplus is done calling w32_gdiplus_startup.
>    Will use it if its available, even if native image functions
>    are disabled.
> - Don't use cl-seq.
> - Use Fexpand_file_name on file name.
> - Send unibyte string only for binary data.
> - Use unwind-protect to ensure temp file is deleted.
> - Fixed docs, changelog, NEWS and manual.

Thanks, there are a few minor nits left.

> Adds the capacity to handle types different from strings to the
> clipboard management functions on MS-Windows, and some logic
> required to convert media types names and content to be what
> yank-media and the modes that use it expect.

Please mention the bug number somwhere in the log message.

> * lisp/term/w32-win.el (w32--selection-target-translations): New
> variable that holds the name translations for media tytpes.
                                                      ^^^^^^
Typo.

> (w32--translate-reverse-selection-target): New function, Reverse
> translation.                                             ^^^^^^^

"reverse", not capitalized.

> * src/w32select.c (stdfmt_name): Made global, was function
> static.                                       ^^^^^^^^^^^^
  ^^^^^^
"was static function"

> (convert_dibv5_to_png): New function to convert DIBV5 clipboard
> format to PNG.
> (get_clipboard_format_name): New function get the name of a
> format given its index.
> (Fw32__get_clipboard_data_media): New function, retrieves and
> converts media content.
> (syms_of_w32select): Export new lisp functions
> * src/w32gdiplus.h: New file, for definitions in w32image.c
> * doc/lispref/frames.texi: Updated with MS-Windows support.

etc/NEWS not mentioned.

> ++++
> +** Emacs on MS-Windows now supports 'yank-media'.
> +This command inserts clipboard data of different formats into the
> +current buffer, if the active mode supports it.
                          ^^^^^^^^^^^
"major mode"

> +(defun w32--translate-selection-target(target)
                                        ^^
We leave one space between the function's name and the opening
parenthesis.  Same issue with other functions you added.

> +  (let ((str (symbol-name mime-type)))
> +    (or
> +     (eq mime-type 'application/xml)
> +     (eq mime-type 'application/json)
> +     (eq mime-type 'application/yaml)
> +     (eq mime-type 'application/json-seq)
> +     (string-match-p "\\`text/" str)
> +     (string-match-p "+xml\\'" str)
> +     (string-match-p "+json\\'" str)
> +     (string-match-p "+yaml\\'" str)
> +     (string-match-p "+json-seq\\'" str))))

This begs for 2 variables and using memq and seq-contains-p.  Or am I
missing something?

> +Elements in FORMATS are symbols naming a format, such a image/png, or
> +image/jpeg.  They don't need to be MIME types, any format available can
> +be retrieved.  For compatibility with X systems, some conventional
> +format names are translated to equivalent MIME types.

Should this mention 'w32--selection-target-translations'?

And I don't understand what you mean by the second sentence above.
Surely, "any format" can be retrieved only if there's a handler for
it?

> +If it returns t, then the file contains the data.

I guess we should add "and the caller should read the file to fetch
the data"?

> +If it returns a string, then that is the data and the file is not used.
> +
> +When returning a string, it can be unibyte if the format is not known to
> +be text.  */)
> +  (Lisp_Object formats, Lisp_Object temp_file_in, Lisp_Object is_textual)

This doc string doesn't say anything about the IS-TEXTUAL argument.

Message #130 received at 71909 <at> debbugs.gnu.org (full text, mbox):

From: Cecilio Pardo <cpardo <at> imayhem.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 71909 <at> debbugs.gnu.org
Subject: Re: bug#71909: 30.0.60;
Date: Sat, 2 Nov 2024 12:24:58 +0100

> 
>> +Elements in FORMATS are symbols naming a format, such a image/png, or
>> +image/jpeg.  They don't need to be MIME types, any format available can
>> +be retrieved.  For compatibility with X systems, some conventional
>> +format names are translated to equivalent MIME types.
> 
> Should this mention 'w32--selection-target-translations'?
> 
> And I don't understand what you mean by the second sentence above.
> Surely, "any format" can be retrieved only if there's a handler for
> it?

Someone may use this function outside of yank-media to get data from the 
clipboard, and handle it herself.

Message #133 received at 71909 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Cecilio Pardo <cpardo <at> imayhem.com>
Cc: 71909 <at> debbugs.gnu.org
Subject: Re: bug#71909: 30.0.60;
Date: Sat, 02 Nov 2024 14:09:58 +0200

> Date: Sat, 2 Nov 2024 12:24:58 +0100
> Cc: 71909 <at> debbugs.gnu.org
> From: Cecilio Pardo <cpardo <at> imayhem.com>
> 
> > 
> >> +Elements in FORMATS are symbols naming a format, such a image/png, or
> >> +image/jpeg.  They don't need to be MIME types, any format available can
> >> +be retrieved.  For compatibility with X systems, some conventional
> >> +format names are translated to equivalent MIME types.
> > 
> > Should this mention 'w32--selection-target-translations'?
> > 
> > And I don't understand what you mean by the second sentence above.
> > Surely, "any format" can be retrieved only if there's a handler for
> > it?
> 
> Someone may use this function outside of yank-media to get data from the 
> clipboard, and handle it herself.

Then maybe this sentence should be removed?  What useful information
does it provide?

Message #136 received at 71909 <at> debbugs.gnu.org (full text, mbox):

From: Cecilio Pardo <cpardo <at> imayhem.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 71909 <at> debbugs.gnu.org
Subject: Re: bug#71909: 30.0.60;
Date: Sat, 2 Nov 2024 21:30:38 +0100

[Message part 1 (text/plain, inline)]

On 02/11/2024 13:09, Eli Zaretskii wrote:
>> Date: Sat, 2 Nov 2024 12:24:58 +0100
>> Cc: 71909 <at> debbugs.gnu.org
>> From: Cecilio Pardo <cpardo <at> imayhem.com>
>>
>>>
>>>> +Elements in FORMATS are symbols naming a format, such a image/png, or
>>>> +image/jpeg.  They don't need to be MIME types, any format available can
>>>> +be retrieved.  For compatibility with X systems, some conventional
>>>> +format names are translated to equivalent MIME types.
>>>
>>> Should this mention 'w32--selection-target-translations'?
>>>
>>> And I don't understand what you mean by the second sentence above.
>>> Surely, "any format" can be retrieved only if there's a handler for
>>> it?
>>
>> Someone may use this function outside of yank-media to get data from the
>> clipboard, and handle it herself.
> 
> Then maybe this sentence should be removed?  What useful information
> does it provide?

I did that. New patch attached with all corrections.

Thank you.

[0001-Add-support-for-yank-media-on-MS-Windows.patch (text/plain, attachment)]

Message #141 received at 71909-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Cecilio Pardo <cpardo <at> imayhem.com>
Cc: 71909-done <at> debbugs.gnu.org
Subject: Re: bug#71909: 30.0.60;
Date: Sun, 03 Nov 2024 15:14:15 +0200

> Date: Sat, 2 Nov 2024 21:30:38 +0100
> Cc: 71909 <at> debbugs.gnu.org
> From: Cecilio Pardo <cpardo <at> imayhem.com>
> 
> On 02/11/2024 13:09, Eli Zaretskii wrote:
> >> Date: Sat, 2 Nov 2024 12:24:58 +0100
> >> Cc: 71909 <at> debbugs.gnu.org
> >> From: Cecilio Pardo <cpardo <at> imayhem.com>
> >>
> >>>
> >>>> +Elements in FORMATS are symbols naming a format, such a image/png, or
> >>>> +image/jpeg.  They don't need to be MIME types, any format available can
> >>>> +be retrieved.  For compatibility with X systems, some conventional
> >>>> +format names are translated to equivalent MIME types.
> >>>
> >>> Should this mention 'w32--selection-target-translations'?
> >>>
> >>> And I don't understand what you mean by the second sentence above.
> >>> Surely, "any format" can be retrieved only if there's a handler for
> >>> it?
> >>
> >> Someone may use this function outside of yank-media to get data from the
> >> clipboard, and handle it herself.
> > 
> > Then maybe this sentence should be removed?  What useful information
> > does it provide?
> 
> I did that. New patch attached with all corrections.

Thanks, installed on master, and closing the bug.

Message #144 received at 71909 <at> debbugs.gnu.org (full text, mbox):

From: Cecilio Pardo <cpardo <at> imayhem.com>
To: 71909 <at> debbugs.gnu.org, eliz <at> gnu.org, aqua0210 <at> foxmail.com
Subject: Re: bug#71909: 30.0.60;
Date: Mon, 4 Nov 2024 23:19:26 +0100

I'm afraid this breaks the build if using --without-native-image-api

We'll need this:



diff --git a/src/w32select.c b/src/w32select.c
index 7e8dc3f0702..9379151f00d 100644
--- a/src/w32select.c
+++ b/src/w32select.c
@@ -825,6 +825,7 @@ DEFUN ("w32-set-clipboard-data", 
Fw32_set_clipboard_data,
 static bool
 convert_dibv5_to_png (char *data, int size, char *temp_file)
 {
+#ifdef HAVE_NATIVE_IMAGE_API
   CLSID clsid_png;

   if (!w32_gdiplus_startup ()
@@ -858,6 +859,10 @@ convert_dibv5_to_png (char *data, int size, char 
*temp_file)
   if (status != Ok)
     return false;
   return true;
+#else
+  return false;
+#endif
+
 }

 static int

Message #147 received at 71909 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Cecilio Pardo <cpardo <at> imayhem.com>
Cc: aqua0210 <at> foxmail.com, 71909 <at> debbugs.gnu.org
Subject: Re: bug#71909: 30.0.60;
Date: Tue, 05 Nov 2024 14:30:26 +0200

> Date: Mon, 4 Nov 2024 23:19:26 +0100
> From: Cecilio Pardo <cpardo <at> imayhem.com>
> 
> I'm afraid this breaks the build if using --without-native-image-api
> 
> We'll need this:

Thanks, installed (and mentioned in NEWS).

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.