GNU bug report logs -
#47032
26.3; doc of `interprogram-paste-function'
Previous Next
Reported by: Drew Adams <drew.adams <at> oracle.com>
Date: Tue, 9 Mar 2021 23:47:01 UTC
Severity: wishlist
Found in version 26.3
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 47032 in the body.
You can then email your comments to 47032 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#47032
; Package
emacs
.
(Tue, 09 Mar 2021 23:47:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Drew Adams <drew.adams <at> oracle.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Tue, 09 Mar 2021 23:47:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
The doc string and (elisp) `Low-Level Kill Ring' say that the function
value of this var can return a "list of strings", to support window
systems that support multiple selections.
Is this a Lisp list of file-name strings? What kind of multiselection
in MS Windows would result in such a list being obtained and returned
by the function value of the var?
I tried this in Windows Explorer, thinking that it might give me such a
list:
1. Select all files in a folder (`C-a'). Or use Control + click to
select several files.
2. Shift + right-click and choose `Copy as Path'.
But (funcall interprogram-paste-function) then returns a string that's
the contatenation of the (absolute) file names, with each name enclosed
in " chars and with those double-quoted names separated by newline chars.
Is that what was meant by a "list of strings"? I'm guessing no, and
that some method of obtaining a Lisp list of strings from multiselection
of file names is intended. But what method, for example?
And if that really was what was meant by a "list of strings" then maybe
that doc could be clarified, because the way it is now I expected a Lisp
list of strings that are (absolute) file names.
In GNU Emacs 26.3 (build 1, x86_64-w64-mingw32)
of 2019-08-29
Repository revision: 96dd0196c28bc36779584e47fffcca433c9309cd
Windowing system distributor `Microsoft Corp.', version 10.0.19041
Configured using:
`configure --without-dbus --host=x86_64-w64-mingw32
--without-compress-install 'CFLAGS=-O2 -static -g3''
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#47032
; Package
emacs
.
(Wed, 10 Mar 2021 12:56:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 47032 <at> debbugs.gnu.org (full text, mbox):
> From: Drew Adams <drew.adams <at> oracle.com>
> Date: Tue, 9 Mar 2021 23:46:37 +0000
>
> The doc string and (elisp) `Low-Level Kill Ring' say that the function
> value of this var can return a "list of strings", to support window
> systems that support multiple selections.
Not "can", "may".
> Is this a Lisp list of file-name strings?
Of course. What other kind of list could be alluded to in the ELisp
manual?
> What kind of multiselection in MS Windows would result in such a
> list being obtained and returned by the function value of the var?
MS Windows doesn't support selections at all, it only supports the
clipboard.
> And if that really was what was meant by a "list of strings" then maybe
> that doc could be clarified, because the way it is now I expected a Lisp
> list of strings that are (absolute) file names.
It's hard to clarify what the manual says because this is not
implemented yet in Emacs, see xselect.c (search for QMULTIPLE).
In a nutshell, this is something we hope will be implemented some day,
and if so, probably only for X selections.
Severity set to 'wishlist' from 'minor'
Request was from
Stefan Kangas <stefan <at> marxist.se>
to
control <at> debbugs.gnu.org
.
(Sat, 25 Sep 2021 15:26:04 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#47032
; Package
emacs
.
(Mon, 20 Jun 2022 08:33:02 GMT)
Full text and
rfc822 format available.
Message #13 received at 47032 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> It's hard to clarify what the manual says because this is not
> implemented yet in Emacs, see xselect.c (search for QMULTIPLE).
>
> In a nutshell, this is something we hope will be implemented some day,
> and if so, probably only for X selections.
So I guess there's nothing to be done here in this bug report, and I'm
therefore closing it.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
bug closed, send any further explanations to
47032 <at> debbugs.gnu.org and Drew Adams <drew.adams <at> oracle.com>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Mon, 20 Jun 2022 08:34:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#47032
; Package
emacs
.
(Mon, 20 Jun 2022 10:04:02 GMT)
Full text and
rfc822 format available.
Message #18 received at 47032 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> It's hard to clarify what the manual says because this is not
> implemented yet in Emacs, see xselect.c (search for QMULTIPLE).
>
> In a nutshell, this is something we hope will be implemented some day,
> and if so, probably only for X selections.
The MULTIPLE target is unrelated to the question at hand, as it only
provides a more efficient way for clients to request multiple targets of
the same selection at once. Emacs also implements the MULTIPLE target,
but only for requests from other clients.
The ICCCM doesn't define a specific "list" format, but it does define
separators for several data types. If you want to respond to a
selection request with a list of file names, then add a selection
converter to `selection-converter-alist' that returns a cons of
`C_STRING' and the encoded file names in a single unibyte string,
separated by NULL bytes.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Mon, 18 Jul 2022 11:24:07 GMT)
Full text and
rfc822 format available.
This bug report was last modified 2 years and 361 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.