Received: (at 72983) by debbugs.gnu.org; 7 Sep 2024 13:48:18 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Sep 07 09:48:18 2024 Received: from localhost ([127.0.0.1]:55201 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1smvnV-0005PS-Oz for submit <at> debbugs.gnu.org; Sat, 07 Sep 2024 09:48:17 -0400 Received: from sonic309-20.consmr.mail.ne1.yahoo.com ([66.163.184.146]:37295) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <luangruo@HIDDEN>) id 1smvnT-0005PE-Td for 72983 <at> debbugs.gnu.org; Sat, 07 Sep 2024 09:48:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1725716889; bh=vjszF4RVG3vDHyJA8IYF2n3yctjsKZ5/Twby+0gCmC8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=uXapaLuOU9bMsxm3i9sAraSbJE9hCBf8n2iev9PlUfPkbWbq9MOAKPB6MJdRAnjYwFhs2QL08S/zuHtOT6ENDOenhWw7jFrMJGYRORcnGuD7uIoHfjRLOzEv/8jcUemc8GCyvaJJo43jzv4gzo3QOfXCjOb52+jTYQP45xYnEf+dhezqGiAg6lXMYSdyOdQD+f0/crcSMIb0TcqtQRiaZ5JnGsaQJzH0mFSekgSq7XlWGLZGAe1McnQ6nViZFsZVLai7OWwDAcqKczi1kxvyZI1LH+BMgI3tKWzE9R7Fv8LLmJilgTJquPIOQmcMTwj5HFHZgwf8iDpFUCSg3dFuYg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1725716889; bh=MrFgk+W6fb3CARXa2N2wGG6l0e0tRAYN5MkGjyJan1G=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=HJNXY49H9ZfIA8ICgG2Up7+pFbQ7AfjVcS4HCSszcpbyY1Q135PT0FYMV5iCeG+uo74R68w3eZqLFH4nx3V1nAtcvyf3Ty37Y28whOFYxlIQvcA7JXbZ8xTap5rsDEJp8t2Y9JavNm8vOdUzrcUbDv/0C/4Q39s1mrbUQDDOzZ9j0SOasumcZ8paVId6xP8qQ2ibTFpB1oUKbbZ4N4t7bRBsCyr0NnskdjtFKk6Gm+1C/JH7f3LD1MQAr8snIHKTy0x/1Ky87MylBKKySR8x2TZPDOPRmOig8lDVwaphiONo8dC7xukUKEBhGAnV7oZlWnwkCsPPkEQdtRubUh74Jg== X-YMail-OSG: fHtnVEcVM1kYMqgswixjUiGYmMeBLbSk.kG410rJwezZ.56my4AQILADhPaV3TN SmEhtJuZpXkSF0F3zJnSWeP4vRu_1UctncBb6Ek5bMbfuJ_coOCRVi1cBbOnHXzu4j5K4Eje.zoD kOYwtZ1BWbVz8tmpvunrMIjaxzzEH2.osr.TyY2NRGM7CXHdx4Xym0jJ_pxg9ruhlzKTQdEU0kDu 4VWNjhFkafGHCo9LsMnXr2iUU6QFFqCiFyWjDFume6TDE3ceoeDf0gfEjwZqFSuGiJjITzO.j1S1 24ZRlTMwYRIUazV2ptoIBFn1QPx8ameV9T4YzIvBIDlU_P7lEYcv6pXHNKbB7ZAp9nowCPSaiTki 8k7kMv0hS_IHWnm2NFKa8fGdnI8kQsYbH13zatsQNrR78z6nsO4dT5wanTcfE0RVXEvvyw9y0rGf 7WSgtryaAEBylXYVExjjCCN_NMG3nzHOEQQ4c.PSq2gYtN8q7PZD3NLdWBO2atXv618nyDgCUQLn qzGfAfZ3qypCo25oIxZxmT.rskTdjB1IelbKEcUNOM3.aRyqt3smgdV97UxfxFXnUgccTjHeQxh3 I0Z8uGyeUS35ua0HYBhFLH4swcoMtTkQe8OiH2QyJyZRWuVkCKmrE5YnBoOBGr17vntKbedTLYUL LN5w2ZE1YfiyUlQzwEst2_aviBwh.PWW7QiLurlCYdHxs8CN5CzwpQXf4So59Pv0v3A1w6wXDATH YwpzTL4k3gPFYp1ZhPLJnwe4tGNVMgok4ng20VtxqEKkNdom_XqDgvRDIQUqam9xiQ_c4UVqAIp8 ydcET90o82Lzaqw3z_UebKqgAk8ttvGuiWldvPb7bUj_sRPaJS65xb3y4b8OWGo0UEyyXfLo8M9w NoOK1pktZ_p4rv38oBdyN96AUEui1Ahuy0JFXxy7ASHQVKMFOuAnI1n7_aV8o8XLFiXypmEMuqyZ O1JdVErMb2CTDnzzJjqJlHq2OCSPbKlfo9g_XAt4jQs4utMnOy6b2UCPEZoUvZN50A4sbzbOKLvn OXFkq4mM1_.72TLPvJbSk5GajawBYUsWnb.1DAYH8sov66d04X_oppNc29j.Ttoc6kmdrF33YGnN gsQLF4HkNj1qV7rHcI0P2tat2alrtjokbwhV8_T_4FsC_stqo8T2nhMCVlWU7GUkHE.sbDIeRPJQ 6PbsuikzzCVjiGfJdQA1_ff78aFr43d1cxOMqDa2_VFS6zH2.MDq.yYKffFZzEZU55vVUfsuummK C_PZduq18tF8a38E_hEpVu6lI3QUbdWUJ.A9JogFOOanaPatnlsjRwhgekLW6fr7VNrH33tYj_iq dRi.t0JgVC0GV7EuPi2yUlNWOmCOqL_i6EsL0qAcVxtuznWjLvOF2SOwNOUg.gzvc5iKRTxbR6c2 UphD7SYkrvOEidIvCyAX1D.6280B9hbE71k70v1xkHuUFys5v7TjBpzvlFakjQtrGP_M51ALozSQ bWwFNsWwSZEC_kOyhbrhDiq5y6P0_AhcgcNaIW2AqVr6vllDOKQ5GhWSV6_RREiMJHacnjvsj_hU sDPlpJeNXTw3QvBah0lx5i8wbkbokm5tLVIovDJdWCG1xqNTeSaHGjoNeUgLgAp4DSgPrcuDGIes u1PRi6t57OBXMi4hX0AmjjZoq6V_YI6K1Cp0bbXSEp53XiIeuAzXf0Qbc289eiHaq2dQpWZU1Ovs x3JzDm0.arPA_arfthWkHUdbRTEhtDsUc.P5_veZAWEQXuTl2ZnAOhiJ_U3su_uWA5YDB2CtSmqw aLhFzBV_D1rl5QKXoWFfWTNk3ZZ2tDGp1V.BIbStKWYELpB1Q.Ag16mgdyVDXas.vzH85AriAew6 fk7_cgS6Lcw43WQgJJvVwfQ95Tu0.zyXZcFUqPoJWptcRyc_tilhMoRpI8aZil0mo46j_F9IDSRA kSPEQw_7aZPjelKRokTKvmGK90mDHkY2aDq503u7Zy._u83rebk0hsmEWB_G5pxWUlYM8iRUKMc9 B.QVwlzqiZdxY2FrGuHJbsvDgNB8X7mrUdHDQPfnapTD3tXnOAgU9QmotRywCqRdSPdQmnA6Leqv EA7Fta2cmqv25edZemrO8V.LEUM0x3l3taylN_XDToB70l0rfuZUNLqxZAYHtT6K5.j.XxDEwZ72 wRrnfGd4TFrSXVDJiffq.VuXLv3la2BoWD9wdbgcManNzx6KjDwsWWHF4DjdX7IeSQW0RGOBUxBO .j5EJaTpAF94UDGoo1dz7mhbSHoEfY2ju634abb_OJVO1QxWylpvw14qmrvavWCGCU17m0g-- X-Sonic-MF: <luangruo@HIDDEN> X-Sonic-ID: cf87258b-39c2-4d27-bf18-3f1dfea238d3 Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.ne1.yahoo.com with HTTP; Sat, 7 Sep 2024 13:48:09 +0000 Received: by hermes--production-sg3-fc85cddf6-5gxlp (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 87c8fca0b54235d118a0fcf0e2181bb7; Sat, 07 Sep 2024 13:48:04 +0000 (UTC) From: Po Lu <luangruo@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#72983: 29.4; Inconsistent parameter types sent to GUI selection converters In-Reply-To: <86seubyft8.fsf@HIDDEN> (Eli Zaretskii's message of "Sat, 07 Sep 2024 12:27:15 +0300") References: <8734mhorar.fsf@HIDDEN> <86seubyft8.fsf@HIDDEN> Date: Sat, 07 Sep 2024 21:47:55 +0800 Message-ID: <87frqbr2wk.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.22645 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 583 X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 72983 Cc: 72983 <at> debbugs.gnu.org, Derek Upham <derek_upham@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Eli Zaretskii <eliz@HIDDEN> writes: > Po Lu, any comments? The facilities that currently exist for customizing selection-converter-alist and the data types returned for a conversion from a string to any particular target are only designed for drag and drop operations, unfortunately. If you remind me of this report after the 30.1 release (or maybe in a number of weeks) I will probably find enough time to address it. At the moment, I'm only willing to attend to issues that affect new functionality introduced in Emacs 30, or absolutely critical issues. Sorry to disappoint.
bug-gnu-emacs@HIDDEN:bug#72983; Package emacs.
Full text available.
Received: (at 72983) by debbugs.gnu.org; 7 Sep 2024 09:27:28 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Sep 07 05:27:28 2024
Received: from localhost ([127.0.0.1]:54834 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1smrj5-0007Sy-CO
for submit <at> debbugs.gnu.org; Sat, 07 Sep 2024 05:27:27 -0400
Received: from eggs.gnu.org ([209.51.188.92]:52516)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <eliz@HIDDEN>) id 1smrj3-0007Sk-DT
for 72983 <at> debbugs.gnu.org; Sat, 07 Sep 2024 05:27:26 -0400
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 <eliz@HIDDEN>)
id 1smriw-0003LU-Lg; Sat, 07 Sep 2024 05:27:18 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From:
Date; bh=mrFVSutsGxczSAigXTZ1Eh9o3rnBB+z9Xfq+/fLCfd0=; b=Fprvy/azAjQ/+4oAahss
uqF1tOzn7DDiknyZEHUxYV2kj3s02revF3YyC4AgsKgp08+JXOG8tS+yFL9JJly3MxrUNEuyNXyhj
+2vgiZBHkb787XcFkvngydSPHS6wW5/hgM4RCCghy0NoilpI4hn0spqbxY9YbEXwYxNkI0eiWV4mI
Tf0VZ86dmdC3HjyeHVeYCIBPwUo2QDzS/Xg1zblYQuYdpAEXdgUZD6JIjezuNdZGqLWagKqQsNhBv
9ayBBMGiUvu5qc3+Pc6p8anE8FC4o1izf8o/901kdyEWKYYZtUA24d6bCSXcGBr8y0qJtoEZHXle/
SiAYotlP3LKBPQ==;
Date: Sat, 07 Sep 2024 12:27:15 +0300
Message-Id: <86seubyft8.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Derek Upham <derek_upham@HIDDEN>,
Po Lu <luangruo@HIDDEN>
In-Reply-To: <8734mhorar.fsf@HIDDEN>
(bug-gnu-emacs@HIDDEN)
Subject: Re: bug#72983: 29.4;
Inconsistent parameter types sent to GUI selection converters
References: <8734mhorar.fsf@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 72983
Cc: 72983 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> Date: Mon, 02 Sep 2024 11:15:40 -0700
> From: Derek Upham via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
>
>
> Existing code
> -------------
>
> We'll have to go into some obscure areas of the GUI selection
> code.
> Let's start with xselect-convert-to-targets (select.el).
>
> (defun xselect-convert-to-targets (selection _type value)
> ;; Return a vector of atoms, but remove duplicates first.
> (if (eq selection 'XdndSelection)
> ;; This isn't required by the XDND protocol, and sure
> enough no
> ;; clients seem to dependent on it, but Emacs implements
> the
> ;; receiver side of the Motif drop protocol by looking at
> the
> ;; initiator selection's TARGETS target (which Motif
> provides)
> ;; instead of the target table on the drag window, so it
> seems
> ;; plausible for other clients to rely on that as well.
> (apply #'vector (mapcar #'intern x-dnd-targets-list))
> (apply #'vector
> (delete-dups
> `( TIMESTAMP MULTIPLENIL
> . ,(delq '_EMACS_INTERNAL
> (mapcar (lambda (conv)
> (if (or (not (consp (cdr
> conv)))
> (funcall (cadr conv)
> selection
> (car conv)
> value))
> (car conv)
> '_EMACS_INTERNAL))
> selection-converter-alist)))))))
>
> This function evaluates each converter in
> selection-converter-alist
> against the selection value, and returns the labels of any
> converters
> that return non-NIL. The goal here is to filter out targets that
> Emacs
> can't vend for the current value. The converters are responsible
> for
> noticing and rejecting inputs that they can't support.
>
> Be aware that the "value" parameter may be a string with text
> properties. The "gui-set-selection" Info documentation mentions
> this:
>
> If DATA is a string, then its text properties can specify
> values
> used for individual data types. For example, if DATA has a
> property named ‘text/uri-list’, then a call to
> ‘gui-get-selection’
> with the data type ‘text/uri-list’ will result in the value
> of that
> property being used instead of DATA itself.
>
> Now compare the xselect-convert-to-targets function with the code
> in
> x_get_local_selection (xselect.c, excerpted).
>
> CHECK_SYMBOL (target_type);
> handler_fn = CDR (Fassq (target_type,
> Vselection_converter_alist));
>
> if (CONSP (handler_fn))
> handler_fn = XCDR (handler_fn);
>
> if (!need_alternate)
> tem = XCAR (XCDR (local_value));
> else
> tem = XCAR (XCDR (XCDR (XCDR (XCDR (local_value)))));
>
> if (STRINGP (tem))
> {
> local_value = Fget_text_property (make_fixnum (0),
> target_type, tem);
>
> if (!NILP (local_value))
> tem = local_value;
> }
>
> if (!NILP (handler_fn))
> value = call3 (handler_fn, selection_symbol,
> ((local_request
> && NILP
> (Vx_treat_local_requests_remotely))
> ? Qnil
> : target_type),
> tem);
> else
> value = Qnil;
>
> The caller (possibly another X client) provides the target, which
> defines the converter to use. If tem is a string, then we check
> for a
> property that matches the target type. If such a property exists,
> we
> clobber the existing string with the associated property's object.
> Then
> we call the converter.
>
>
> Problem
> -------
>
> This discrepancy trips up potential HTML support.
>
> A typical application like Firefox or LibreOffice vends both
> text/html
> and text/plain content. Clients will ask for the targets, then
> ask
> for the text/html value if available, falling back to text/plain.
> For
> example, we might want to support an italiced "foo", while falling
> back to the underlying word.
>
> #("foo" 0 3 (text/html "<i>foo</i>"))
>
> We want to advertise a text/html target only when our value has a
> text/html property. We can do that with new
> "xselect-convert-to-html"
> function in selection-converter-alist.
>
> (text/html . xselect-convert-to-html)
>
> The function returns true if the input is a string with a
> text/html
> property. But if the client then *asks* for the text/html, the C
> code
> will send the same function a plain string “<i>foo</i>” without
> the
> property. The function bails out with NIL. Most clients will
> then fall
> back and ask for the text/plain target.
>
> In broad terms, we can’t distinguish between regular text and HTML
> text
> from first principles. We need guidance from upstream. Also note
> that
> if we write the HTML converter function such that it doesn’t test
> for
> and require that text/html property, then Emacs will happily vend
> the
> plain text strings to text/html requesters.
>
>
> Possible fixes
> --------------
>
> The current implementation doesn't nail down the protocol and the
> data types.
>
> There are a couple of potential fixes; some are more invasive than
> others.
>
> 1. We can define that, if we have a string, then the string is
> always
> implicitly a variant type that we pass the converters. Just
> take out
> the local_value clobbering in the C code. The HTML converter
> and all
> other converters can then consistently look for and extract
> their
> relevant property from the string. This is a breaking behavior
> change, but for already-broken behavior. And the built-in
> converters
> in select.el don’t seem to care about those properties.
>
> 2. We can put the properties back in. Once we extract the
> property
> string local_value, copy the properties of the original string
> tem
> into local_value. Then overwrite tem. The rule for handlers
> is then
> to *look* for the property, but it can use property’s string or
> the
> underlying string.
>
> 3. We can declare that callers have to add type tags to the
> property objects.
>
> #("foo" 0 3 (text/html (html . "<i>foo</i>")))
>
> Then the converters are responsible for receiving that string
> *or*
> (html . "<i>foo</i>"), depending on which function calls them,
> handling both inputs. This is ugly, but it works for a
> prototype
> HTML converter on top of the existing v29.4 code.
Po Lu, any comments?
bug-gnu-emacs@HIDDEN:bug#72983; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 2 Sep 2024 18:17:03 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Sep 02 14:17:03 2024
Received: from localhost ([127.0.0.1]:50277 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1slBbr-0008CC-1W
for submit <at> debbugs.gnu.org; Mon, 02 Sep 2024 14:17:03 -0400
Received: from lists.gnu.org ([209.51.188.17]:36556)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <derek_upham@HIDDEN>) id 1slBbo-0008Bh-It
for submit <at> debbugs.gnu.org; Mon, 02 Sep 2024 14:17:01 -0400
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 <derek_upham@HIDDEN>)
id 1slBak-0005qD-Al
for bug-gnu-emacs@HIDDEN; Mon, 02 Sep 2024 14:15:58 -0400
Received: from wilbur.contactoffice.com ([212.3.242.68])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <derek_upham@HIDDEN>)
id 1slBai-0004FW-07
for bug-gnu-emacs@HIDDEN; Mon, 02 Sep 2024 14:15:54 -0400
Received: from smtpauth2.co-bxl (smtpauth2.co-bxl [10.2.0.24])
by wilbur.contactoffice.com (Postfix) with ESMTP id D4731160D
for <bug-gnu-emacs@HIDDEN>; Mon, 2 Sep 2024 20:15:45 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1725300945;
s=20240605-akrp; d=mailfence.com; i=derek_upham@HIDDEN;
h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding;
bh=iwsvbifLmeUFL3XIR+XBWV5fXOBgAHr5YFSRjLs4Uws=;
b=SOBkk5OVDYIW+32JSS5bDMf3EzKU84DOaWI/yvkS8Rq1awwaTm0E8p2XeOo/XTqh
BG0R+NwoDBYrcjODE64h4WYD7BFV+dhm/rRBZfu57dfII/6nx5+A1Mp/UxhXYE3Ta3v
Zudhfwd1LoftTxeTh5xCfiewzFitrFka6490HA2Lul3hdSEBeqQdoyl/a0ZmScEU6ug
/w62LBvx2ym2ccEev0kA9yUdOwBy+ylfkqPK0UxICUg121XaDhGyxnA+EBfE2ULFsQv
1tTUO5AwZFx27tq7nwWRGc7KZrIKtKhdGoSv48SUwqY/GR+2bcpKWgKq5bYqaSLqZwP
Wsu38IVaHw==
Received: by smtp.mailfence.com with ESMTPSA
for <bug-gnu-emacs@HIDDEN> ; Mon, 2 Sep 2024 20:15:43 +0200 (CEST)
Received: from [::1] (helo=priss.frightenedpiglet.com)
by priss.frightenedpiglet.com with esmtps (TLS1.3) tls
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.97)
(envelope-from <derek_upham@HIDDEN>)
id 1slBaX-000000030OL-0wYj; Mon, 02 Sep 2024 11:15:41 -0700
From: Derek Upham <derek_upham@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: 29.4; Inconsistent parameter types sent to GUI selection converters
Date: Mon, 02 Sep 2024 11:15:40 -0700
Message-ID: <8734mhorar.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-ContactOffice-Account: com:175140567
Received-SPF: pass client-ip=212.3.242.68;
envelope-from=derek_upham@HIDDEN; helo=wilbur.contactoffice.com
X-Spam_score_int: -27
X-Spam_score: -2.8
X-Spam_bar: --
X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001,
RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001,
SPF_HELO_NONE=0.001, SPF_PASS=-0.001,
T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.4 (-)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.4 (--)
Existing code
-------------
We'll have to go into some obscure areas of the GUI selection=20
code.
Let's start with xselect-convert-to-targets (select.el).
(defun xselect-convert-to-targets (selection _type value)
;; Return a vector of atoms, but remove duplicates first.
(if (eq selection 'XdndSelection)
;; This isn't required by the XDND protocol, and sure=20
enough no
;; clients seem to dependent on it, but Emacs implements=20
the
;; receiver side of the Motif drop protocol by looking at=20
the
;; initiator selection's TARGETS target (which Motif=20
provides)
;; instead of the target table on the drag window, so it=20
seems
;; plausible for other clients to rely on that as well.
(apply #'vector (mapcar #'intern x-dnd-targets-list))
(apply #'vector
(delete-dups
`( TIMESTAMP MULTIPLENIL
. ,(delq '_EMACS_INTERNAL
(mapcar (lambda (conv)
(if (or (not (consp (cdr=20
conv)))
(funcall (cadr conv)=20
selection
(car conv)=20
value))
(car conv)
'_EMACS_INTERNAL))
selection-converter-alist)))))))
This function evaluates each converter in=20
selection-converter-alist
against the selection value, and returns the labels of any=20
converters
that return non-NIL. The goal here is to filter out targets that=20
Emacs
can't vend for the current value. The converters are responsible=20
for
noticing and rejecting inputs that they can't support.
Be aware that the "value" parameter may be a string with text
properties. The "gui-set-selection" Info documentation mentions=20
this:
If DATA is a string, then its text properties can specify=20
values
used for individual data types. For example, if DATA has a
property named =E2=80=98text/uri-list=E2=80=99, then a call to=20
=E2=80=98gui-get-selection=E2=80=99
with the data type =E2=80=98text/uri-list=E2=80=99 will result in the =
value=20
of that
property being used instead of DATA itself.
Now compare the xselect-convert-to-targets function with the code=20
in
x_get_local_selection (xselect.c, excerpted).
CHECK_SYMBOL (target_type);
handler_fn =3D CDR (Fassq (target_type,=20
Vselection_converter_alist));
if (CONSP (handler_fn))
handler_fn =3D XCDR (handler_fn);
if (!need_alternate)
tem =3D XCAR (XCDR (local_value));
else
tem =3D XCAR (XCDR (XCDR (XCDR (XCDR (local_value)))));
if (STRINGP (tem))
{
local_value =3D Fget_text_property (make_fixnum (0),
target_type, tem);
if (!NILP (local_value))
tem =3D local_value;
}
if (!NILP (handler_fn))
value =3D call3 (handler_fn, selection_symbol,
((local_request
&& NILP=20
(Vx_treat_local_requests_remotely))
? Qnil
: target_type),
tem);
else
value =3D Qnil;
The caller (possibly another X client) provides the target, which
defines the converter to use. If tem is a string, then we check=20
for a
property that matches the target type. If such a property exists,=20
we
clobber the existing string with the associated property's object.=20
Then
we call the converter.
Problem
-------
This discrepancy trips up potential HTML support.
A typical application like Firefox or LibreOffice vends both=20
text/html
and text/plain content. Clients will ask for the targets, then=20
ask
for the text/html value if available, falling back to text/plain.=20
For
example, we might want to support an italiced "foo", while falling
back to the underlying word.
#("foo" 0 3 (text/html "<i>foo</i>"))
We want to advertise a text/html target only when our value has a
text/html property. We can do that with new=20
"xselect-convert-to-html"
function in selection-converter-alist.
(text/html . xselect-convert-to-html)
The function returns true if the input is a string with a=20
text/html
property. But if the client then *asks* for the text/html, the C=20
code
will send the same function a plain string =E2=80=9C<i>foo</i>=E2=80=9D wit=
hout=20
the
property. The function bails out with NIL. Most clients will=20
then fall
back and ask for the text/plain target.
In broad terms, we can=E2=80=99t distinguish between regular text and HTML=
=20
text
from first principles. We need guidance from upstream. Also note=20
that
if we write the HTML converter function such that it doesn=E2=80=99t test=20
for
and require that text/html property, then Emacs will happily vend=20
the
plain text strings to text/html requesters.
Possible fixes
--------------
The current implementation doesn't nail down the protocol and the=20
data types.
There are a couple of potential fixes; some are more invasive than=20
others.
1. We can define that, if we have a string, then the string is=20
always
implicitly a variant type that we pass the converters. Just=20
take out
the local_value clobbering in the C code. The HTML converter=20
and all
other converters can then consistently look for and extract=20
their
relevant property from the string. This is a breaking behavior
change, but for already-broken behavior. And the built-in=20
converters
in select.el don=E2=80=99t seem to care about those properties.
2. We can put the properties back in. Once we extract the=20
property
string local_value, copy the properties of the original string=20
tem
into local_value. Then overwrite tem. The rule for handlers=20
is then
to *look* for the property, but it can use property=E2=80=99s string or=
=20
the
underlying string.
3. We can declare that callers have to add type tags to the=20
property objects.
#("foo" 0 3 (text/html (html . "<i>foo</i>")))
Then the converters are responsible for receiving that string=20
*or*
(html . "<i>foo</i>"), depending on which function calls them,
handling both inputs. This is ugly, but it works for a=20
prototype
HTML converter on top of the existing v29.4 code.
--=20
Derek Upham
derek_upham@HIDDEN
Derek Upham <derek_upham@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#72983; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.