Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Emacs Tramp over AWS SSM APIs

martin.baillie.id

Post reply on HN
Print view View original

11–20 of 59 posts

Re: Emacs Tramp over AWS SSM APIs

#11

Post by ak217 »

natrys wrote: post #9
ak217 wrote: post #6

Earlier quoted context omitted.

Yes, the vscode remote development plugin is a game changer. It's the new benchmark for how client-server IDEs should work. I am (and more importantly, my team is) no longer constrained to the terminal and memorizing incredibly obscure emacs or vi commands to get stuff done on a remote instance. There is no input lag because vscode keeps all the IDE UI local while doing all the heavy lifting remotely. And to the arti…

Emacs isn't constrained by terminal, Tramp doesn't need knowing any "incredibly obscure" command, and since one uses local Emacs there is no input lag to speak of. I feel like you are conflating Emacs and Vi here even though they are not same at all, only in case of Vi you connect via ssh in a terminal and do everything remote side, not in Emacs. I use Tramp to have local Emacs connect to remote docker container, whe…

To be clear, I was only mentioning vi and emacs together because both have incredibly passionate communities that can be quite myopic to the UX deficiencies of their platforms. I have a lot of muscle memory committed to emacs so I still use it a lot, but I can onboard a dozen junior developers onto vscode in the time it takes me to help someone figure out emacs. And to me, the final missing piece that made vscode suitable as a general purpose replacement for emacs was the remote dev plugin.

Re: Emacs Tramp over AWS SSM APIs

#12

Post by taeric »

Scarbutt wrote: post #10
taeric wrote: post #5

Earlier quoted context omitted.

How? Tramp has been working at this level for well over a decade, if I'm not mistaken. And you don't have to have anything installed in the "host" that you are connecting to.

When your dev environment is on a remote server, the DX of vscode is superior, everything just works(like all your plugins), it's seamless and fast. Tramp is great for editing some remote files here and there, but to match vscode you will have to put a lot of effort to make everything feel equally fast and make all your packages work. Even then it won't feel as seamless as vscode because it "cheats" by installing a r…

If you install any auxiliary dev tools on the remote, it will work just as seamlessly. Git, lsp, etc.

I confess that you need a solid ssh connection. But for the most part it has been great for a long time.

Re: Emacs Tramp over AWS SSM APIs

#13

Post by squiddev »

taeric wrote: post #5
Scarbutt wrote: post #4

Earlier quoted context omitted.

vscode ate everyone's lunch in this department.

How? Tramp has been working at this level for well over a decade, if I'm not mistaken. And you don't have to have anything installed in the "host" that you are connecting to.

If you're working on very slow network connections, or the network just dies entirely, it's not uncommon for Emacs just to hang entirely. You then have to kill Emacs from another terminal. At the time I was running exwm (an Emacs window manager), which made the whole thing even more painful. Emacs is powerful, but polish is not its strong point.

That said, this was a few years ago now. Things may have improved in 26.1 when threads were introduced, and async got even easier.

Re: Emacs Tramp over AWS SSM APIs

#14

Post by tyingq »

"Perhaps more interesting, though, is that for the last couple of years AWS has supported tunneling the SSH protocol over their SSM APIs if you use the SSM “document” called AWS-StartSSHSession."

That's interesting. I know some places go to great lengths to keep developers from accessing production without some sort of break-glass procedure through a jump host. I'm curious if they all know about this sort of loophole.

Re: Emacs Tramp over AWS SSM APIs

#16

Post by xemdetia »

ak217 wrote: post #6
Scarbutt wrote: post #4

Earlier quoted context omitted.

vscode ate everyone's lunch in this department.

Yes, the vscode remote development plugin is a game changer. It's the new benchmark for how client-server IDEs should work. I am (and more importantly, my team is) no longer constrained to the terminal and memorizing incredibly obscure emacs or vi commands to get stuff done on a remote instance. There is no input lag because vscode keeps all the IDE UI local while doing all the heavy lifting remotely. And to the arti…

I'm confused with claiming obscure emacs or vi commands for TRAMP, I'm from the emacs side and as soon as I understood the file path scheme (e.g.: /ssh:$host:/path/to/file) I didn't have to do anything beyond that.

I would say that the dev client/server setup you're describing and what TRAMP provides are different things overall as well. TRAMP really just provides a way to get a file from a remote, edit it locally, and on save write it back to the remote system. I would not consider it a valid use case for remote dev especially now with how prevalent things like LSP's are and I don't know of a major mode that is designed around a remote LSP I'd just do X forwarding or some other screen share at that point. I would agree that overall it's a gap for emacs that VS Code does better.

Re: Emacs Tramp over AWS SSM APIs

#17

Post by ak217 »

dangom wrote: post #7
ak217 wrote: post #6

Earlier quoted context omitted.

Yes, the vscode remote development plugin is a game changer. It's the new benchmark for how client-server IDEs should work. I am (and more importantly, my team is) no longer constrained to the terminal and memorizing incredibly obscure emacs or vi commands to get stuff done on a remote instance. There is no input lag because vscode keeps all the IDE UI local while doing all the heavy lifting remotely. And to the arti…

I'd love to see a workflow comparison between emacs, vim (with remote work via neovim's tcp support + neovide) and vscode. I'm currently using Emacs and have a pretty decent setup for remote work with jupyter-emacs and tramp, and it's pretty much 0 overhead to run the same code on multiple remotes, or have the same remote run code stored in multiple places. With that said, all abstractions end if my SSH connection br…

I don't think the level of integration between tramp and other essential emacs plugins (flycheck, jedi, magit, etc.) is comparable to vscode. In vscode, entire plugins responsible for this stuff are sent over to run on the remote, leaving the local to run the UI - but also to keep all the settings and state.

In emacs I have to either add pretty complicated scripts to my .emacs just to get stuff to play together if it's even possible at all, or stay in the terminal and run it all on the remote (and put up with the lag, and re-mount/upload my configuration when a new instance starts).

For the longest time I used emacs on the remote and pycharm/jetbrains locally (and was a vscode skeptic) - that changed once I saw what the remote dev plugin was capable of (jetbrains doesn't have an equivalent). I still use emacs in the terminal on remotes for quick text editing, but for project work vscode works better specifically because it's easier to resume on disconnect (one-click restore of all state) and easier to configure. I use tmux in the vscode terminal to resume remote shell sessions.

More importantly, it's a lot easier to onboard others to vscode because the IDE as a whole is more discoverable, more user-friendly, and follows platform conventions more closely compared to emacs or vi.

The one big feature that I miss in vscode is tab key behavior/intelligent indentation. Emacs does this way better - tab just does what I mean, instead of inserting a useless literal tab or spaces.

Re: Emacs Tramp over AWS SSM APIs

#18

Post by mjw1007 »

xemdetia wrote: post #16
ak217 wrote: post #6

Earlier quoted context omitted.

Yes, the vscode remote development plugin is a game changer. It's the new benchmark for how client-server IDEs should work. I am (and more importantly, my team is) no longer constrained to the terminal and memorizing incredibly obscure emacs or vi commands to get stuff done on a remote instance. There is no input lag because vscode keeps all the IDE UI local while doing all the heavy lifting remotely. And to the arti…

I'm confused with claiming obscure emacs or vi commands for TRAMP, I'm from the emacs side and as soon as I understood the file path scheme (e.g.: /ssh:$host:/path/to/file) I didn't have to do anything beyond that. I would say that the dev client/server setup you're describing and what TRAMP provides are different things overall as well. TRAMP really just provides a way to get a file from a remote, edit it locally, a…

TRAMP is more than just opening and writing files: it runs VCS operations remotely, which is very helpful.

https://emacs-lsp.github.io/lsp-mode/page/remote/ suggests that LSP under TRAMP is basically there, though I haven't had occasion to try it.

Re: Emacs Tramp over AWS SSM APIs

#19

Post by WaxProlix »

tyingq wrote: post #14

"Perhaps more interesting, though, is that for the last couple of years AWS has supported tunneling the SSH protocol over their SSM APIs if you use the SSM “document” called AWS-StartSSHSession." That's interesting. I know some places go to great lengths to keep developers from accessing production without some sort of break-glass procedure through a jump host. I'm curious if they all know about this sort of loophole…

As the article states, it's completely controlled by IAM and whatever federated identity management you hook up to AWS, and the events are auditable via cloudtrail etc.

Re: Emacs Tramp over AWS SSM APIs

#20

Post by ithrow »

taeric wrote: post #5
Scarbutt wrote: post #4

Earlier quoted context omitted.

vscode ate everyone's lunch in this department.

How? Tramp has been working at this level for well over a decade, if I'm not mistaken. And you don't have to have anything installed in the "host" that you are connecting to.

Every time you save your edits Tramp makes a new connection to the remote server, it's slow(1sec vs 1ms) and becomes annoying waiting for the save all the time. For doing quick edits it doesn't matter but for doing dev all day it does.
Post reply on HN