Very interesting. In the past, I have resorted to using a combination of Sam/9term/plumber in similar scenarios, but I really prefer Acme. At the moment I'm running Acme over X11, since I'm constrained to using Windows on the desktop, and I've got a working X server, but no Acme on Windows. Anyone got plan9port to work under Cygwin?
On Mon, Jan 4, 2021 at 5:41 AM marius a. eriksen <[email protected]> wrote: > Lately, I have needed to do a great deal of my work on remote servers. > It's been difficult to do this with acme. Previously, I have attempted to > run acme entirely remotely, and then attach to a local devdraw instance > <https://github.com/mariusae/devdrawserver>. This works okay, but also > has many drawbacks, among which: (1) it's not economical with networking, > and so not great for high latency or otherwise poor connections; (2) it's > not resilient to connection disconnects; (3) often I want access to local > resources too. > > I built an experimental remoting layer in acme to see how far I could get > in recreating a modern "remoting" experience with acme. Since acme itself, > of course, is designed around a bunch of 9p servers, this turned out to be > fairly easy to do, and the resulting experience is nearly transparent. > > A remote may be attached to one or more path prefixes. These are similar > to mount points in a file system. Thus, if the prefix /home/meriksen is > attached to the remote "dev", then any file with this prefix is transparely > fetched from the dev. Similarly, when commands are run from any directory > with this prefix, the command is transparently run on the remote. The > command is run in an environment that includes the acme and plumber 9p > servers (forwarded from the local host), and so even acme programs just > work. For example, if you run 'win' from a directory that is attached to a > remote, 'win' is run on the remote host, but it accesses the acme 9p file > tree (which is forwarded from the local acme) and creates its window and > interacts with acme. It "just works". (I regularly run other programs like > this too, e.g., acme-lsp, which uses the plumber to coordinate interaction). > > The design of the feature is quite simple: a new program, acmesrv > <https://github.com/mariusae/plan9port/tree/marius/src/cmd/acme/acmesrv> is > run by acme (through ssh) on the remote host. Acme becomes a client of > acmesrv, through which all further interaction is facilitated. Acmesrv > itself is really just a 9p multiplexer: the local acme program exports the > acme and plumber 9p servers; acmesrv provides two new 9p servers (exportfs > and cmdfs) that gives the local acme access to the remote's file system > (exportfs) and to run commands (cmdfs). > > The local acme manages a session for each remote, and properly deals with > session disconnect/reconnect, etc. Thus, poor network conditions and > disconnects are easily supported. Since acme's file handling is anyway > stateless (the file is not kept open during editing), file state is easily > maintained through disconnect-reconnect cycles. > > There are some synchronous code paths in acme, and these may cause > temporary freezes when using remoting. For example, when acme queries for > the existence of a file (stat), this blocks UI updates in acme. On session > establishment (e.g., the first time a file is accessed on a remote), this > can cause additional delays, since the file cannot be queried before first > establishing a new session. I've not found this to be a big deal. > > This has been my "daily driver" for about a month at this point, and > overall I'm very happy with the experience. It creates a nearly transparent > experience editing remote files, and retains most of acme's functionality > in remote settings as well. I never hesitate to shut my laptop lid while in > the middle of a project. Most things just work. There are wrinkles, of > course, and there are some sharp edges in this (experimental) > implementation, but, to me, this provides really very useful functionality > that lets me use acme in more challenging environments. (Not to mention > that this means I can use a beefy remote host for heavy lifting.) > > In case this would be useful to anyone else, this version of acme resides > in my plan9port tree on github > <https://github.com/mariusae/plan9port/tree/marius/src/cmd/acme>. > (Currently, these diffs: 1 > <https://github.com/mariusae/plan9port/commit/dd56712c9d09fc89e8cb0e0b2ead42e1d52698cd#diff-574485e893cad2d30bfacb77bb02cc2d44b1a363f867006c24989689cdf18ada>, > 2 > <https://github.com/mariusae/plan9port/commit/a74049761a902a88502c9dfd3acd3f97591073d5#diff-574485e893cad2d30bfacb77bb02cc2d44b1a363f867006c24989689cdf18ada>, > 3 > <https://github.com/mariusae/plan9port/commit/edeba6c4cb652f99d4de79d151fd94b8eea7988f#diff-574485e893cad2d30bfacb77bb02cc2d44b1a363f867006c24989689cdf18ada>, > 4 > <https://github.com/mariusae/plan9port/commit/2fa8e435b6fedb7914bb6a2d7e1f48bba784ccdb#diff-574485e893cad2d30bfacb77bb02cc2d44b1a363f867006c24989689cdf18ada> > .) > > -m. > > (And of course, I realize that this approach goes against the spirit of > acme and plan9 -- acmesrv here is recreating a very specific slice of > functionality that could be recreated by standard means if we had real > filesystems. But we don't live in that world, and this is immensely useful > to me.) > *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions > <https://9fans.topicbox.com/groups/9fans> + participants > <https://9fans.topicbox.com/groups/9fans/members> + delivery options > <https://9fans.topicbox.com/groups/9fans/subscription> Permalink > <https://9fans.topicbox.com/groups/9fans/T5addc17a0e19cd91-Mcb2e189b0570c6833f195230> > ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T5addc17a0e19cd91-M1347b1d8513480d11627e4eb Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
