From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Derek Upham via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#72983: 29.4; Inconsistent parameter types sent to GUI selection converters Date: Mon, 02 Sep 2024 11:15:40 -0700 Message-ID: <8734mhorar.fsf@priss.frightenedpiglet.com> Reply-To: Derek Upham Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3968"; mail-complaints-to="usenet@ciao.gmane.io" To: 72983@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Sep 02 20:17:17 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 1slBc5-0000qO-7F for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 02 Sep 2024 20:17:17 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1slBbr-0005tb-N0; Mon, 02 Sep 2024 14:17: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 1slBbp-0005tQ-JZ for bug-gnu-emacs@gnu.org; Mon, 02 Sep 2024 14:17:01 -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 1slBbp-0004JR-A8 for bug-gnu-emacs@gnu.org; Mon, 02 Sep 2024 14:17:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-Version:Date:From:To:Subject; bh=iwsvbifLmeUFL3XIR+XBWV5fXOBgAHr5YFSRjLs4Uws=; b=mAzzD9MGzmIAf0QWfrTKs0JMyJxCv2kCikeeBa0//bO8PiytgxiGs/A39ti037u0vxx7ioHt8UsuZb5ilrjn0C/CTHb9icYbMQzqoy1DgnzbmFgrZrbjOM1ktFDSRxsViwPz9c2F2mlMNNuLyNnWu7JPCb18UR0lOWSrzd1PC/8ZfcxVqBuWiGF5c6/3lR3KW6p6xR5Vq9a0+DhW7njLZGXomihKbOcfIbh1ispiYvR3OKXSHwuUJhVb4udack1cMuSBIGzv/FmNoYgILL9QW9+HbwB5pMIZufC/rKmgWB1Klx10tSF/RS2/qj9YSP2YNtpCZDA0/croHauP/A7AzA==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1slBco-0008EI-0H for bug-gnu-emacs@gnu.org; Mon, 02 Sep 2024 14:18:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Derek Upham Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 02 Sep 2024 18:18:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 72983 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.172530102331514 (code B ref -1); Mon, 02 Sep 2024 18:18:01 +0000 Original-Received: (at submit) by debbugs.gnu.org; 2 Sep 2024 18:17:03 +0000 Original-Received: from localhost ([127.0.0.1]:50277 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1slBbr-0008CC-1W for submit@debbugs.gnu.org; Mon, 02 Sep 2024 14:17:03 -0400 Original-Received: from lists.gnu.org ([209.51.188.17]:36556) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1slBbo-0008Bh-It for submit@debbugs.gnu.org; Mon, 02 Sep 2024 14:17:01 -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 1slBak-0005qD-Al for bug-gnu-emacs@gnu.org; Mon, 02 Sep 2024 14:15:58 -0400 Original-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 ) id 1slBai-0004FW-07 for bug-gnu-emacs@gnu.org; Mon, 02 Sep 2024 14:15:54 -0400 Original-Received: from smtpauth2.co-bxl (smtpauth2.co-bxl [10.2.0.24]) by wilbur.contactoffice.com (Postfix) with ESMTP id D4731160D for ; 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@mailfence.com; 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== Original-Received: by smtp.mailfence.com with ESMTPSA for ; Mon, 2 Sep 2024 20:15:43 +0200 (CEST) Original-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 ) id 1slBaX-000000030OL-0wYj; Mon, 02 Sep 2024 11:15:41 -0700 X-ContactOffice-Account: com:175140567 Received-SPF: pass client-ip=212.3.242.68; envelope-from=derek_upham@mailfence.com; 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-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:291115 Archived-At: 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 "foo")) 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=9Cfoo=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 . "foo"))) Then the converters are responsible for receiving that string=20 *or* (html . "foo"), 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@mailfence.com