From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#71909: 30.0.60; Date: Tue, 29 Oct 2024 16:25:29 +0200 Message-ID: <86plnj56li.fsf@gnu.org> References: <865xtnhyn6.fsf@foxmail.com> <58c79a62-cd21-4ff5-8e81-a9ba3e9b2097@imayhem.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29004"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 71909@debbugs.gnu.org To: Cecilio Pardo Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Oct 29 15:27:33 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1t5nC0-0007HH-Vm for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 29 Oct 2024 15:27:33 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t5nBX-00044J-Tx; Tue, 29 Oct 2024 10:27:03 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t5nBW-000443-Dv for bug-gnu-emacs@gnu.org; Tue, 29 Oct 2024 10:27:02 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1t5nBW-00006n-6C for bug-gnu-emacs@gnu.org; Tue, 29 Oct 2024 10:27:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=References:In-Reply-To:From:Date:To:Subject; bh=lEf2sh4iYlbexBY/7qgoxY4E0qZQc9UnhwLyguV3LUE=; b=ZMYoZ9qDbMfjOL0/yHrSPw2/2k3UDIldhQ+BXcKkI5PXzSPua8F0WLBes2VXJmTleMbw5Z59vmy8fKNiNKlN/VkNUcwqsM9JQZuRsHPN1puAOKkVy+WS2HWjnJQCyuW5gr8MSax0m5m9+hC9zZ2faF0q7ZvEPY1e0fL5+dmMdLBEogbByJHWPb4eOVlgm52RsEhnjXi6o8E6x2kJ2dB58OWat9QAMTr1x2JAox+J3JSwjfxK5+1mynsNSADpLuBsnm+HIsghtNNBeIkq5LtmKecP7OSmIYQG8jrMa/kSEkJ6l0kl9B3UwKExsLKJuqaX/U5Fdt09jRJdjkkNz5CaaQ==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1t5nBV-0006hE-Mu for bug-gnu-emacs@gnu.org; Tue, 29 Oct 2024 10:27:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 29 Oct 2024 14:27:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 71909 X-GNU-PR-Package: emacs Original-Received: via spool by 71909-submit@debbugs.gnu.org id=B71909.173021196225706 (code B ref 71909); Tue, 29 Oct 2024 14:27:01 +0000 Original-Received: (at 71909) by debbugs.gnu.org; 29 Oct 2024 14:26:02 +0000 Original-Received: from localhost ([127.0.0.1]:56627 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t5nAX-0006gS-Gd for submit@debbugs.gnu.org; Tue, 29 Oct 2024 10:26:02 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:51722) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t5nAU-0006gI-Ms for 71909@debbugs.gnu.org; Tue, 29 Oct 2024 10:25:59 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t5nAL-0008NB-Rw; Tue, 29 Oct 2024 10:25:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=lEf2sh4iYlbexBY/7qgoxY4E0qZQc9UnhwLyguV3LUE=; b=C/zYLFraVfN4 QUnk75xICfATJzlWl2DdJx0XhVznKYoAv9vYDg+KgD/mcXH4+WaeIzGkCldY8DwOKkBg1+vyRwzA1 XNVK6gldj6V9S5Yq+Oyugf3q3AZqI8u63QABrvSlroJx1GL5OOLrG6wSOrQU1Z0rG9b/f8Ji5T1xd V3ZaxGdeK17k/StXzhxxwKNu7cX3Wql7tUxj4g+0+KmyvF4DM5Df72KSiH6YErUPwsM9cmjnSr1Bj omsjnAAgnRvsHrAOnf2lvQxeMASJVFm5E69EbtylBcYKwut+U0bVS11YO580Ry11JyM12GMR7pMK9 i7npYxe9l6tllnzvSKUkKw==; In-Reply-To: <58c79a62-cd21-4ff5-8e81-a9ba3e9b2097@imayhem.com> (message from Cecilio Pardo on Mon, 28 Oct 2024 22:46:36 +0100) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:294493 Archived-At: > Date: Mon, 28 Oct 2024 22:46:36 +0100 > From: Cecilio Pardo > > 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).