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 . 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 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 . (Currently, these diffs: 1 , 2 , 3 , 4 .) -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: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T5addc17a0e19cd91-Mcb2e189b0570c6833f195230 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription