Re: [9fans] Mac p9p snarf buffer

["Russ Cox" <rsc@swtch.com>]

I made some X fixes that solve at least half the problem Rob reported.

	cd $PLAN9/src/cmd/devdraw; mk install; mk clean

on the machines where the apps are running (which might not
be the Mac if you are using ssh -X to run remote X apps).

I have no good answer for Skip's problem -- X11 shouldn't even
be involved.  The rest of this mail is an explanation of the 
various problems.

There are many different moving parts here, and each configuration can
produce a different failure (or success).


+ X11 selections v.  Pasteboard

X11 doesn't have a snarf buffer.  Instead it has an idea of which
window currently "owns" the snarf (X11 would say `selection'), and
when you want to find the snarf contents you go ask the current owner.
There is no central buffer like on Plan 9's /dev/snarf or the Windows
clipboard.  (In addition to making things a lot more complicated, this
means that snarf contents do not persist once their owner exits.  But
that particular problem isn't relevant here.)

OS X does have a snarf buffer, called the Pasteboard.  There are
programs pbcopy and pbpaste that come with OS X that write to and read
from the Pasteboard.

The OS X X11 server has the unenviable task of making the X11 madness
interoperate with native OS X. As far as the snarf buffer is
concerned, it's job should be to synchronize in both directions:

  * Every time an OS X app writes to the pasteboard, X11 should claim
  to own the snarf, and when apps request the snarf from it, it should
  serve the request using the pasteboard contents.

  * Every time an X11 app claims the snarf, X11 should fetch the snarf
  from it and write to the pasteboard.

Bug #1: some versions of the OS X X11 server require you to select
"Copy" from the X11 Edit menu before fetching the snarf and writing it
to the pasteboard.

To work around bug #1, p9p apps on OS X write directly to the
pasteboard themselves rather than depend on the X11 server.  nm
$PLAN9/bin/devdraw | grep Pasteboard should confirm this.

Unfortunately, this workaround does not work when running an app on a
remote machine via ssh -X.  Then the only connection to the local
pasteboard is via X11 so apps are at its mercy.


+ X11 selection updates

As best I can tell, if you own the snarf then another app can send you
an XSelectionRequest request, which turns into an
XSelectionRequestEvent event.  Then you copy the snarf into a public
attribute on the X11 server using XChangeProperty and use XSendEvent
to send an XSelectionEvent to the requestor (the id is in the initial
request) to tell it that the snarf is ready.

Bug #2.  On OS X using ssh -X forwarding, the X11 server does not let
the final XSendEvent run.  Instead it returns with an error and the
app often gives up.  I was trying this with "X11 1.1.3 - XFree86
4.4.0", ssh -X to Linux, and then running xterm or gtkedit or leafpad,
and they all crashed after the server rejected one message or another.
So remote apps seem not to be very reliable in some versions of X11 on
OS X.


+ X11 selection formats

X11 allows (nay, encourages) selections to be arbitrary blocks of
data.  When you fetch the snarf from an owner, the first thing you do
is ask for a list of possible formats.  Then you look in the format
list for one that sounds good to you.  The most common is "STRING".
Other apps are free to make up names for other strings.  Most seem to
have standardized on "UTF8_STRING" for a UTF-8 string, though some do
things like "text/plain;charset=UTF-8".

Bug #3 (fixed).  It had been working okay to respond to all these
various kinds of strings with UTF-8 data and to ask for plain "STRING"
and hope it would be UTF-8.  Apparently on OS X that is not okay
anymore -- when you ask for "STRING" from the X11 server it replaces
non-ASCII characters with ?.

I changed p9p to try "UTF8_STRING" before trying "STRING", and now
pasting UTF-8 into p9p apps on OS X works for me.

I tried to reproduce the "garbage out when copying UTF-8 from p9p to
OS X" but it works fine for me locally.  Because of Bug #2 I can't
tell whether copying UTF-8 from a remote X11 window to a local OS X
app produces garbage or not.  I changed the returned format list to
mention "UTF8_STRING" before "STRING", so that apps that request the
format list (not all do) and look for the first one they like will
prefer UTF-8.


+ Avoiding X11

Paul Lalonde suggested using native OS X bindings instead of relying
on X11.  This is a good idea and one that I hope will happen soon,
but it won't entirely solve the problem.  People do run remote
X apps via ssh -X, and most of the problems (like Bug #3) would
have eventually cropped up on the other X-based systems if left
unfixed.  So while I encourage having a native OS X devdraw,
we still need to figure out how to play nice with the OS X X11.

Russ