Hacker News Reader

Comment by dleink | Hacker News Reader

Any tips or resources on running remotely over ssh? I'd like to set up a dev environment that I can access remotely and/or from various devices.

Also what do you mean by, "learned as a language" wrt to vim keybindings?

View on HN

> Any tips or resources on running remotely over ssh? I'd like to set up a dev environment that I can access remotely and/or from various devices.

I first started by getting a free VPS from Oracle and setting up my computer to use autossh to always maintain a connection to the VPS so that I could access it through reverse tunnel over any kind of NAT. I use a key pair for authentication to make it secure. I also use mosh to make it easier to reconnect when moving around.

Then anything that can be done locally over a terminal can also be done remotely over ssh. I try to avoid anything graphical. You can use tmux or screen to do terminal multiplexing, or if stay inside Emacs, you can do the terminal multiplexing without separate tools by using multiple windows with terminal buffers.

So basically you can slowly convert your workflow to run on a terminal when working locally, and if you make your machine accessible remotely, then you will naturally start to use it also when working remotely.

> Also what do you mean by, "learned as a language" wrt to vim keybindings?

I think the original idea of "learned as a language" came from reading this stackoverflow entry [1], but when learning I looked also to other references. [1] https://stackoverflow.com/a/1220118

> "Also what do you mean by, "learned as a language" wrt to vim keybindings?"

Vim isn't a hodgepodge of ad-hoc keyboard shortcuts like, say, typical Windows programs ("where shall we put search and replace? Ctrl+H is free, done"). It can be seen more as a small domain-specific language for text manipulation. "d2w" is delete twice word (delete two words). "yy4p" is copy line 4x paste (copy this line four times below).

It's built of verbs (or operators, like delete, yank, make-uppercase), counts, movements (motions, like up,down,to end of line, to end of word, to start of next word, to search match) and objects (like characters, words, lines, paragraphs, blocks inside braces, text inside quotes, 'the selection') and you compose them together to say what editing you want to do on the text.

":help gU" will tell you that gU makes {motion} uppercase, that means you can do gUe to uppercase to the end of the current word, gU2e to uppercase to the end of the next word, gUfx to uppercase until the next x character, gU/thing to uppercase until the regex search for 'thing' matches...

and Vim being around a long time, it has a lot of different verbs, motions, objects to allow you to slice and dice your text just so for the edits you want to make.

Try

    :help motion
    :help word-motions
    :help operator
    :help objects

ah yes, I am decent Vim user but hadn't thought about it in that context. Thanks for the context!

Sometimes ssh -C helps on slow connections. Also mosh is great for those cases, but optional and has different setup requirements (see below). As others have said start a -daemon on remote and use emacsclient -nw when you connect. Spend some time finding a local terminal client that works well and invest in tuning its quirks to make it support all of the Emacs keys and full 32bit colors. I had good luck with iTerm2 from a Mac and with kitten or basic xterm on Linux, but any solution required at least a handful of nontrivial modifications for full support of the terminal powers. Once you have the local machine become a thin client a lot of development is easy and much faster than any other mode of operation; plus if you change the local machine nothing changes except a one time setup of a terminal.

In the Emacs world, this is done using TRAMP[0]. This allows you to treat remote systems over various protocols (usually ssh) as an extension to the local system. So you wouldn't use Emacs over ssh, but rather ssh over Emacs.

[0] https://www.gnu.org/software/tramp/tramp-emacs.html

You can do both. I often ended up running emacs on a remote server using ssh/tmux as it was easier to keep my state on said server (processes etc) and just reconnect.

Sure, but not being able to access your local system with your text editor is a bit strange to me. If you know that you won't need to then there is no problem with that though.

I generally had a local emacs for all that stuff.

At the place(s) I did this, pretty much all dev took place on remote servers so it was pretty normal for a lot of people.

on my current setup, from a thin-client I remote desktop to a windows machine where I vnc to a xvnc linux server, from which I ssh -X to a large shared dev machine. From there I run gui emacs, often using TRAMP to access remote files.

The amazing thing is that this contraption is actually usable.

Single biggest bugbear for me using emacs over SSH (non-TRAMP, remote-ssh and run emacs --daemon and then emacsclient -t locally on that machine) is on a laptop, I find that the session drops frequently and I need to reconnect (sometimes after hitting return-tilde-dot to unfreeze the dead terminal session). I've never really figured out how to fully stabilize my SSH (and I certainly don't have anything as convenient as "Actually auto-restores the session if it breaks," which is something vscode seems capable of doing for the shells it opens).

Second bugbear is running in terminal so all my GUI conveniences are missing, but it's emacs so that's a distant second to the first.

I just use tmux on the remote, so just run in terminal on that machine.

Agreed with the GUI stuff, needing to write graphs to a specific file and have a web server was super, super annoying.

Reply on news.ycombinator.com