simon-git: xclipglue (master): Simon Tatham

Sat Apr 18 08:31:06 BST 2020

TL;DR:
  5d7a58a Better handling of a refused MULTIPLE request.
  a8d16d8 Factor out our standard destination property atoms.
  ed1dd0b get_property: don't crash if the property isn't there.
  a024fb9 Handle the MULTIPLE property having been cleared.
  21de66c Tweak exit condition to allow short-lived runs.
  11aaa78 Handle SelectionRequest with property=None.
  65e2284 Add representation for None in "32a" property format.
  e9ff7a8 atoms_to_strings: fallback handling of None.
  4892591 MULTIPLE selection data type should be ATOM_PAIR, not ATOM.
  13743a6 Treat an absent destination property as a failed conversion.
  ec38f49 Handle two different interpretatins of MULTIPLE.
  6d5c4d9 Forgot to set req.multiple!

Repository:     https://git.tartarus.org/simon/xclipglue.git
On the web:     https://git.tartarus.org/?p=simon/xclipglue.git
Branch updated: master
Committer:      Simon Tatham <anakin at pobox.com>
Date:           2020-04-18 08:31:06

commit 5d7a58a8e6ed7e67c6091fd42152c254eb3a99bb
web diff https://git.tartarus.org/?p=simon/xclipglue.git;a=commitdiff;h=5d7a58a8e6ed7e67c6091fd42152c254eb3a99bb;hp=467098e355915344e57ced98817ca6815a9324e3
Author: Simon Tatham <anakin at pobox.com>
Date:   Sat Apr 18 06:58:28 2020 +0100

    Better handling of a refused MULTIPLE request.

    If the SelectionNotify responding to a MULTIPLE request has atom=None,
    indicating that the whole request was refused, we should treat it the
    same as if the selection owner had accepted the outer MULTIPLE
    transfer and then individually refusing everything in it. In other
    words, we should return a "rsp" command containing the right number of
    "none". In fact we were only returning a single "none".

    (Not that any selection owner _should_ be refusing MULTIPLE - it's
    supposed to accept the framing request even if it doesn't support any
    of the targets inside it. But undoubtedly there will be badly behaved
    selection owners that don't know this wrinkle of ICCCM, and we should
    at least handle them in a way that won't overly confuse xclipglue or
    its peer.)

 xclipglue.cpp | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

commit a8d16d8e05c7c8d98c6edf2dee03e0dfe312eae1
web diff https://git.tartarus.org/?p=simon/xclipglue.git;a=commitdiff;h=a8d16d8e05c7c8d98c6edf2dee03e0dfe312eae1;hp=5d7a58a8e6ed7e67c6091fd42152c254eb3a99bb
Author: Simon Tatham <anakin at pobox.com>
Date:   Sat Apr 18 07:02:01 2020 +0100

    Factor out our standard destination property atoms.

    I'm about to need the dest properties we use in a MULTIPLE transfer in
    two different parts of the code. While I'm at it, factor out our
    single destination atom as well, on general principles of tidiness.

 xclipglue.cpp | 13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

commit ed1dd0bfa46d018d825d75ef4c85dedaa12f9cc6
web diff https://git.tartarus.org/?p=simon/xclipglue.git;a=commitdiff;h=ed1dd0bfa46d018d825d75ef4c85dedaa12f9cc6;hp=a8d16d8e05c7c8d98c6edf2dee03e0dfe312eae1
Author: Simon Tatham <anakin at pobox.com>
Date:   Sat Apr 18 07:02:54 2020 +0100

    get_property: don't crash if the property isn't there.

    If we try to retrieve a window property that doesn't exist,
    GetProperty signals that by returning None as the type atom. But
    get_property() would fail to check that before passing it to
    GetAtomName, which means that even if we had a good way to _handle_
    the property being absent, we wouldn't get as far as being able to,
    because get_property would have exited with an error before even
    getting to that point.

 xclipglue.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

commit a024fb97c7792bd8ae0a732250c11a26faf1d5ae
web diff https://git.tartarus.org/?p=simon/xclipglue.git;a=commitdiff;h=a024fb97c7792bd8ae0a732250c11a26faf1d5ae;hp=ed1dd0bfa46d018d825d75ef4c85dedaa12f9cc6
Author: Simon Tatham <anakin at pobox.com>
Date:   Sat Apr 18 07:04:20 2020 +0100

    Handle the MULTIPLE property having been cleared.

    When you make a MULTIPLE selection request to emacs, I observe that by
    the time it returns, it has deleted the destination property you wrote
    to the window. But this doesn't indicate that it's refused the
    request: it has still written all the data you wanted into the
    subsidiary destination properties.

    So I've revised the handling of MULTIPLE responses to say: _if_ the
    atom-list property still exists, _and_ if it's long enough to contain
    an atom in the place of the destination property for a given
    subtarget, _and_ if that atom is None, _then_ we conclude that the
    selection owner has refused that particular sub-request. Otherwise, we
    proceed as if everything was normal.

    So now we can do MULTIPLE transfers from emacs successfully.

 xclipglue.cpp | 19 +++++++++++++------
 1 file changed, 13 insertions(+), 6 deletions(-)

commit 21de66c32b879923d49dee1faf1b18069fbe2504
web diff https://git.tartarus.org/?p=simon/xclipglue.git;a=commitdiff;h=21de66c32b879923d49dee1faf1b18069fbe2504;hp=a024fb97c7792bd8ae0a732250c11a26faf1d5ae
Author: Simon Tatham <anakin at pobox.com>
Date:   Sat Apr 18 07:10:43 2020 +0100

    Tweak exit condition to allow short-lived runs.

    Now, if we receive a command on the input pipe and then it immediately
    closes, we don't terminate until we've replied to that final command.

    In particular, this means you can use xclipglue -stdio as an engine to
    do just one selection request, by saying something like

      xclipglue -stdio <<<"req PRIMARY foo STRING"

    and you should get the answer to that one request on standard output
    before xclipglue terminates.

 xclipglue.cpp | 17 +++++++++++++++--
 1 file changed, 15 insertions(+), 2 deletions(-)

commit 11aaa786e9595a408fcabe24044b35557cd7ba45
web diff https://git.tartarus.org/?p=simon/xclipglue.git;a=commitdiff;h=11aaa786e9595a408fcabe24044b35557cd7ba45;hp=21de66c32b879923d49dee1faf1b18069fbe2504
Author: Simon Tatham <anakin at pobox.com>
Date:   Sat Apr 18 07:25:24 2020 +0100

    Handle SelectionRequest with property=None.

    An old and deprecated technique used by outdated X clients, according
    to ICCCM. Use the recommended handling.

 xclipglue.cpp | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

commit 65e22841cd1f32b9272d5507898a307587989658
web diff https://git.tartarus.org/?p=simon/xclipglue.git;a=commitdiff;h=65e22841cd1f32b9272d5507898a307587989658;hp=11aaa786e9595a408fcabe24044b35557cd7ba45
Author: Simon Tatham <anakin at pobox.com>
Date:   Sat Apr 18 07:54:13 2020 +0100

    Add representation for None in "32a" property format.

    This is a protocol change, albeit a small one. When I defined the wire
    format for a list of X atom values in an X property, I forgot that
    None is a valid value for an ATOM integer which has no string
    translation. So I've defined a small wrinkle in which that's
    represented as "-", and a literal "-" atom name must therefore be
    represented by %-encoding the minus sign.

 xclipglue.but |  6 +++++-
 xclipglue.cpp | 34 ++++++++++++++++++++++++++--------
 2 files changed, 31 insertions(+), 9 deletions(-)

commit e9ff7a875b50d91ecadc747528c3ce96da03db05
web diff https://git.tartarus.org/?p=simon/xclipglue.git;a=commitdiff;h=e9ff7a875b50d91ecadc747528c3ce96da03db05;hp=65e22841cd1f32b9272d5507898a307587989658
Author: Simon Tatham <anakin at pobox.com>
Date:   Sat Apr 18 07:55:32 2020 +0100

    atoms_to_strings: fallback handling of None.

    After the previous commit, this function _shouldn't_ receive None in
    an atom under normal circumstances any more. But it's just conceivable
    that someone might SendEvent us a bogus X event of some kind, so this
    should at least mean we don't crash on receiving it.

 xclipglue.cpp | 22 +++++++++++++++++-----
 1 file changed, 17 insertions(+), 5 deletions(-)

commit 4892591730256ae6b0f39bfecbf10cad09034c7a
web diff https://git.tartarus.org/?p=simon/xclipglue.git;a=commitdiff;h=4892591730256ae6b0f39bfecbf10cad09034c7a;hp=e9ff7a875b50d91ecadc747528c3ce96da03db05
Author: Simon Tatham <anakin at pobox.com>
Date:   Sat Apr 18 07:56:39 2020 +0100

    MULTIPLE selection data type should be ATOM_PAIR, not ATOM.

 xclipglue.cpp | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

commit 13743a62ec4d6d733482142dab108f47b41dc205
web diff https://git.tartarus.org/?p=simon/xclipglue.git;a=commitdiff;h=13743a62ec4d6d733482142dab108f47b41dc205;hp=4892591730256ae6b0f39bfecbf10cad09034c7a
Author: Simon Tatham <anakin at pobox.com>
Date:   Sat Apr 18 08:07:03 2020 +0100

    Treat an absent destination property as a failed conversion.

    That's better than returning it as the empty string.

 xclipglue.cpp | 2 ++
 1 file changed, 2 insertions(+)

commit ec38f4961d4bff2e438577b47953327b6842b565
web diff https://git.tartarus.org/?p=simon/xclipglue.git;a=commitdiff;h=ec38f4961d4bff2e438577b47953327b6842b565;hp=13743a62ec4d6d733482142dab108f47b41dc205
Author: Simon Tatham <anakin at pobox.com>
Date:   Sat Apr 18 08:10:40 2020 +0100

    Handle two different interpretatins of MULTIPLE.

    I've just found out that xterm and pterm - or rather, xterm and GTK3 -
    disagree on which atom of a pair you should zero out in the MULTIPLE
    property when a sub-transfer fails. Sigh.

    So now, when we're checking what the selection owner has done to _our_
    property, we detect either one being zeroed out; and when we are the
    selection owner, we zero out both, just in case!

 xclipglue.cpp | 30 +++++++++++++++++++++---------
 1 file changed, 21 insertions(+), 9 deletions(-)

commit 6d5c4d978be9ccb9f6c018b2390422ec8523c4f3
web diff https://git.tartarus.org/?p=simon/xclipglue.git;a=commitdiff;h=6d5c4d978be9ccb9f6c018b2390422ec8523c4f3;hp=ec38f4961d4bff2e438577b47953327b6842b565
Author: Simon Tatham <anakin at pobox.com>
Date:   Sat Apr 18 08:28:28 2020 +0100

    Forgot to set req.multiple!

    But it only makes a difference when you're refusing one of the
    transfers in a MULTIPLE.

 xclipglue.cpp | 1 +
 1 file changed, 1 insertion(+)