From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Cecilio Pardo Newsgroups: gmane.emacs.bugs Subject: bug#71909: 30.0.60; Date: Wed, 30 Oct 2024 10:05:08 +0100 Message-ID: <3b0ad17c-aa6e-421c-a17a-453bf0483023@imayhem.com> References: <865xtnhyn6.fsf@foxmail.com> <58c79a62-cd21-4ff5-8e81-a9ba3e9b2097@imayhem.com> <86plnj56li.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1962"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird To: 71909@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Oct 30 10:06:28 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 1t64eq-0000ON-Cj for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 30 Oct 2024 10:06:28 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t64eV-0003zt-5D; Wed, 30 Oct 2024 05:06:07 -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 1t64eS-0003za-50 for bug-gnu-emacs@gnu.org; Wed, 30 Oct 2024 05:06:04 -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 1t64eQ-0004HA-Ow for bug-gnu-emacs@gnu.org; Wed, 30 Oct 2024 05:06:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=In-Reply-To:From:References:MIME-Version:Date:To:Subject; bh=5WCmYNbgG3e/Ju8HtlC4DPEqf1EY/6YSVYxOCbyOwJE=; b=MXSqzGDUTG2hfJgho0niAa5F4h5wDCCCcmc9WHXPtWgz0JGpa0i3JDto+uTYcZYFtpmNdi3ilvODOEVAupx3tNnlBUNWHdXEr7VZQ3VqvEEsKg/FbSGJrhGaZ9uBEZ3FW5C28V1Xf93NaH0OsefPY27qjpK8E5EC9rokIblMIYlLMQktjkmq3rE9aFQlo83u/0uF/MpoxvwxSwCfMZT2pyP5aQ25ygcTLrxyemrG9TX6cI4RSV2vSIfDNz+SLr+Vpyma5gd/PHs3CXPTh0kJX/42BdB3a2NC/SWDsu0Knex5v7QHRxhoP9xhundQYHcMlEFtdkd/aDK+5IJNAzMTdQ==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1t64eQ-00018i-Ds for bug-gnu-emacs@gnu.org; Wed, 30 Oct 2024 05:06:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Cecilio Pardo Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 30 Oct 2024 09:06:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 71909 X-GNU-PR-Package: emacs X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.17302791274329 (code B ref -1); Wed, 30 Oct 2024 09:06:02 +0000 Original-Received: (at submit) by debbugs.gnu.org; 30 Oct 2024 09:05:27 +0000 Original-Received: from localhost ([127.0.0.1]:34143 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t64dq-00017l-Oo for submit@debbugs.gnu.org; Wed, 30 Oct 2024 05:05:27 -0400 Original-Received: from lists.gnu.org ([209.51.188.17]:42972) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t64do-00017d-JU for submit@debbugs.gnu.org; Wed, 30 Oct 2024 05:05:25 -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 1t64di-0003xO-IW for bug-gnu-emacs@gnu.org; Wed, 30 Oct 2024 05:05:19 -0400 Original-Received: from mail.imayhem.com ([82.223.54.191] helo=zealous-pike.82-223-54-191.plesk.page) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1t64dg-0004DV-CN for bug-gnu-emacs@gnu.org; Wed, 30 Oct 2024 05:05:18 -0400 Original-Received: from [192.168.68.104] (111.red-88-21-7.staticip.rima-tde.net [88.21.7.111]) by zealous-pike.82-223-54-191.plesk.page (Postfix) with ESMTPSA id 481698012E for ; Wed, 30 Oct 2024 09:05:09 +0000 (UTC) Authentication-Results: zealous-pike.82-223-54-191.plesk.page; spf=pass (sender IP is 88.21.7.111) smtp.mailfrom=cpardo@imayhem.com smtp.helo=[192.168.68.104] Received-SPF: pass (zealous-pike.82-223-54-191.plesk.page: connection is authenticated) Content-Language: es-ES In-Reply-To: <86plnj56li.fsf@gnu.org> Received-SPF: pass client-ip=82.223.54.191; envelope-from=cpardo@imayhem.com; helo=zealous-pike.82-223-54-191.plesk.page X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:294550 Archived-At: >> 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?