Make plan9port dependency optional by default

[fhs]

This issue tracks various issues that are preventing us from removing plan9port as a default dependency.

devdraw:

• duitdraw is slow. In X11, pprof points to swizzle as the primary culprit.
• segfault on resize in macOS: x/mobile: App exits with Segmentation Fault golang/go#12718
• duitdraw is missing MoveTo and/or SetCurosor in Windows and macOS
• In X11, clipboard is used for snarf/paste but not primary selection
• Support for $PLAN9/lib/keyboard input
• xauth issue when running tests using duitdraw in Travis CI?

9pserve:

• mux9p crashes sometimes: crash due to concurrent map read and map write fhs/mux9p#2

fontsrv:

• freetype crashes sometimes: freetype crashes occasionally in GlyphAdvance ktye/duitdraw#17
• uncompressed Plan 9 fonts served by fontsrv can't be loaded by plan9font (used by duitdraw)

[pf10]

is it possible to keep plan9port as an optional alternative to whatever go-only solutions being implemented?

standalone devdraw allows for network transparent gui. right now it's possible to multiplex remote unix duit apps into a plan9 terminal, or do a remote connection to an app from any mac or unix. outside of windows plan9port is likely to be present in all the acme deployments since it provides significant infrastructure that's not reproducible in Go right now (though various utilities are being rewritten).

I guess a bigger question that should be addressed to the duit community, is the duitdraw going to remain feature compatible with plan9 draw protocol. with such a tight integration there's a temptation to ignore existing capabilities and hack something fancy, that would be difficult to retroport into plan9 draw protocol. is there edwood developer position on this question?

thanks!

[fhs]

I wasn't thinking of network transparency. I don't mind keeping plan9port dependency for that.

I guess what I really meant is that go get ... shouldn't require the user to install plan9port. We'd use duitdraw or whatever other native Go GUI library by default and make plan9port dependency optional with a build tag. Right now it's the other way around: we use devdraw by default and enable duitdraw with a build tag.

[pf10]

I agree an out-of-the-box working editor, that doesn't require complicated dependencies is an excellent goal :) just hoping that the power users are not lost in the process. even just generally having some clarity on the question helps. right now one of the greatest accidental advantages of duit is that it's network transparent, and it's pretty easy to write a custom backend for it. i have a pile of hacks that let me devdraw to a linux framebuffer for example, which i use for kiosks and interactive installations. being able to popup an edwood window to do some live debugging is a cool feature. but i can also see how that's a very niche application.