Cloudmacs: access your Emacs in browser
beepb00p.xyz
beepb00p.xyz
I feel like a grumpy fossil for asking this, but if your problem is “Sometimes you have to use non-personal computers where it's not possible/undesirable to install desktop Emacs,” why not run emacs the way it has been run in exactly those sorts of situations for almost 50 years? Remotely, via shell?
Is the hat trick here that by stuffing emacs into a docker container and accessing it over the web you can consume like 10,000 times the energy and resources of just running it over ssh in a terminal window as God intended ?
Sorry sorry that was a rude question. Now please get off my lawn.
(Honestly though I ran emacs for 5+ years entirely on an overtaxed Sun workstation shared with dozens if not hundreds of other students, over ssh, and it was fine! I believe I even had color working. I began at 14.4kbps and went from there. I saw the machine once, maybe twice.)
You know what? This project is doing exactly that; using Emacs remotely, via a terminal (not a shell BTW, shell is just a name for some specific language’s interpreter, that is good at launching sub processes).
It’s using the gotty[0] library, which is an implementation of the tty[1] in the browser.
It’s a natural extension; ttys have been ported for a few decades, starting from teleprinters[2] to text terminals[3] and terminal emulators[4].
[0] https://github.com/yudai/gotty
[1] https://en.m.wikipedia.org/wiki/Terminal_emulator
[2] https://en.m.wikipedia.org/wiki/Teleprinter
I have personally implemented Linux workstations where access to the terminal or any shell is prohibited.
Primary reason is that computers where I run it might not have shell and emacs installed in the first place, so I can't connect to a remote port.
However you got me thinking: do you know any emacsclient implementations that run purely in browser? Presumably that would be not that hard to implement and will make more sense.
Although I still think I'd not expose emacs daemon to the outside: it's basically shell, so if I was doing it, I'd dockerize it anyway.
Ugh.
So I did this. Not recently, but in the late 90s/early 2000s.
Our startup was moved across the street from its incubator (Idealab). WiFi wasn't a thing, broadband was far from mainstream, and most generic office space wasn't wired for networking. So we had a microwave link (I think) connecting our workspace to fat pipes across the street.
For anything interactive, it was awful. Waiting >500ms for each keystroke to appear is a very difficult experience.
Thankfully after a week or two, I discovered TRAMP mode.[1]
- Gotty is a tool that allows accessing any TTY app as a web page (also allows forwarding input)
- We use Gotty to run emacsclient --tty -a '' command, that connects to the existing Emacs instance or starts a new one. That makes the session persist tab closing, connection problems etc.
- Your Emacs configs and files you want to expose to Cloudmacs are mapped in docker-compose.yml file.
Rest of the setup is basically dirty business of setting up Docker container, permissions etc.
There is WeTTY, too, that is based on xterm.js, which seems interesting. This one is listed in the readme of Gotty.
1. Press the three dots to the right of the url. 2. Click more tools on the drop down menu. 3. Finally "create shortcut".
This should let you open that website in a mode where it hijacks relatively few keyboard shortcuts, so that `C-N`, `C-W`, etc, work. I don't think it gets all of them though.
Would like to be able use latex-preview in something like this.
This setup: https://github.com/JAremko/browsermax seems to deal with X, but not sure if it actually still works, and looks quite complicated.
Could however be better from security perspective if you don't want to expose a shell and the whole filesystem to potentially untrusted computers.
[1] https://github.com/karlicoss/cloudmacs/blob/master/asEnvUser [2] https://security.stackexchange.com/a/153016
Although a section explaining how to build container that runs as non-root user in the first place (even though it requires modifying Dockerfile, I think) would be useful, so I'll add it, thanks!
Yep, potential kernel/Docker bugs would let you escape the sandbox, but I guess that's the risk I'm accepting.