Hacker News Reader

Comment by chongli | Hacker News Reader

The point of an editor having tons of plugins is captured in one phrase: the long tail [1]. A mature tool with a healthy ecosystem of plugins will have every user installing a unique (or nearly unique) suite of plugins. Attempting to have the base tool itself support all those millions of different use cases and configurations is a lost cause.

[1] https://en.wikipedia.org/wiki/The_Long_Tail_(book)

View on HN

You're just reinforcing my point instead of addressing it, the tail of plugins you need is not available everywhere

The plug-ins are for the home environment, customized to be ideal and cover all bases. Like a home office.

The core functionality being available everywhere means a familiar and efficient, even if not ideal and complete, suite is available everywhere else: servers, other computers, a new system. For transient / temporary use. Like on a business trip, a flight, or the conference.

Except it's neither familiar nor efficient because, e.g., you're using your custom keybindings in your "home office" (and there are a dozen of more things that become integral to your editing experience), all of which would break down your basics.

Just like you wouldn't use a random laptop during a business trip and expect to be efficient, you'd bring your own!

A data point: I'm a plugin-heavy neovim user, and I wholeheartedly testify that familiarity with vi modal editing is incredibly useful when ssh-ing into remote systems, and I don't have my plugins.

Not to disagree, but these days vscode (and probably others, but vscode is the best I've tried) mostly alleviates that need with remote editing. It also has a few objective benefits, like eliminating typing latency (e.g. if your remote machine is on the other side of the globe), and letting you keep all your local settings and extensions (mostly).

I def wanna try that out sometime!

It does sound to me like that is not a consequence of the GUI-ness of VSCode, but just the man-hours that go into making it. In other words, it doesn't sound like that experience can't be replicated in terminal-only editors.

If anyone has experience with remote editing in a terminal editor, but not through an ssh shell (ie, the traditional way), I'm very interested in hearing your experience.

> If anyone has experience with remote editing in a terminal editor, but not through an ssh shell (ie, the traditional way), I'm very interested in hearing your experience.

As usual, emacs has a mode for everything:

https://www.emacswiki.org/emacs/TrampMode

Emacs’ TRAMP works well (it’s been available since at least '99, and has been built-in for as long as I can remember), and supports most everything (ssh, ftp, docker, whatever you can get at with rclone, ...). It also works fine with dired (the built-in file manager), eshell, whatever.

The mostly-single-threaded nature of Emacs gets in the way sometimes.

Except I'm sure that book fails to mention many examples where the long tail worked and instead focuses on where the long tail failed and biases it's own story around that.

Jetbrains suite of IDEs are basically long tails and they have huge utility in many areas that exceed other editors.

Reply on news.ycombinator.com