Seems to work very well. Excellent! There is one thing that is a bit strange, though. Unless I explicitly list my home directory as one of the remote paths, acme simply does not connect to the remote machine at all. No big deal, though.
Another slight issue is that because acme loads whole files, opening a huge file may take quite a bit of time. Sam avoids this issue by only loading the file on the remote, and transfers only what is needed to refresh the display. But that's just a different tradeoff. All in all I think I prefer your acme, especially since it can run acme-lsp on the remote.

On Wed, Jan 12, 2022 at 5:06 AM marius a. eriksen <marius@monkey.org> wrote:
> So I thought about sam, which I also like, although I have not used it as much as acme. Sam has remote editing, which solves the latency and bandwidth problem, but I prefer the acme right-click to navigate compilation errors and grep results. So, can we combine acme and sam in a meaningful way? It turns out we can. From a local acme, I connect to the remote Docker in one or more acme windows. This is for compilation and grep. By adding plumber rules which sends any file which cannot be found locally to the remotely connected sam, I can right-click on errors and grep results and get sam to go there. The only thing is that to avoid recursion in the plumber, I must specifically route the message to the sam named pipe instead of to the edit port, which means I need to start sam before the plumber. Also, I have not investigated how I can access the remote clangd from my local acme.

An alternative is this patch which implements a proper remoting layer for Acme. (Very similar to the way Sam does it: it starts a server over ssh, and then ferries 9p back and forth.)

I use this as my daily driver, and it's _very_ close to a local experience.

See this thread for some more details.




On Thu, Oct 21, 2021 at 11:16 AM Ole-Hjalmar Kristensen <ole.hjalmar.kristensen@gmail.com> wrote:
Not exactly Hell, but rather close: 
ISPOrganizationLatitudeLongitude
NTE Marked ASNot Available63.433310.6833
😀

This is the tale of a convoluted development environment, not specifically Plan9, but Plan9port, sam, and acme.

I am working on a largish system, with about 5M LOC. The setup is as follows. I have a Windows laptop. It needs to be Windows, because of the office automation applications. It is also the only machine I have at home which can connect to the company VPN. The office desktop is a nice modern AMD Ryzen 9 16-core processor with plenty of RAM running Ubuntu. The system cannot (for reasons beyond my control) be compiled on the Ubuntu, it needs specifically CentOS 7, so we run a Docker image with CentOS 7 on the Ubuntu machine. Compiling on the laptop is a no-go anyway, it is much too slow, so I have not bothered installing WSL and Docker on it.

I started out running VSCode, which is available both on Windows and Ubuntu, and which has nice remote editing capabilities a la sam, and tons of plugins. It is a better experience then Visual Studio, in my opinion. It has a clangd plugin which can be used to navigate the code, but for some reason clangd chokes on some submodules. acme with acme-lsp gives me the same navigation capabilities, and I prefer the user interface of acme, so I have reverted to acme on the Ubuntu machine. Works great, I use acme-lsp on the modules clangd manages to compile, and ag (parallel grep-like tool) on the rest. So in the office, everything is hunky-dory. I connect to the Docker image from acme by running win docker exec, and since both Docker and the Ubuntu machine has the same view of the files, everything works seamlessly.

When working from home, acme is not an ideal solution, since the VPN network has high latency and relatively low bandwith (a fraction of my 500Mbit fiber connection). I run an X server on Windows, and start acme on the Ubuntu machine. Editing files works fairly well, but commands which spew large amounts of text really bogs acme down. I could switch to VSCode, but I would prefer not to.

Now, I have experimented with other solutions which could give me a better experience. Running sshfs and a local acme would be one possibility, but it is not really fast enough for searching through the code. (I can search the 5M lines code base in about 2 seconds with ag on the desktop machine). Copying the whole system to the local machine and do the editing locally, then run Unison to synchronize, is another possibility, but not ideal.

So I thought about sam, which I also like, although I have not used it as much as acme. Sam has remote editing, which solves the latency and bandwidth problem, but I prefer the acme right-click to navigate compilation errors and grep results. So, can we combine acme and sam in a meaningful way? It turns out we can. From a local acme, I connect to the remote Docker in one or more acme windows. This is for compilation and grep. By adding plumber rules which sends any file which cannot be found locally to the remotely connected sam, I can right-click on errors and grep results and get sam to go there. The only thing is that to avoid recursion in the plumber, I must specifically route the message to the sam named pipe instead of to the edit port, which means I need to start sam before the plumber. Also, I have not investigated how I can access the remote clangd from my local acme.

What do you think? Suggestions?