Why do you care so much about availability of an app that is unusable without a lot of plugins? At which point, you can copy plugin code with the editor app to a place you need it available in
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.
Just like you wouldn't use a random laptop during a business trip and expect to be efficient, you'd bring your own!
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.
As usual, emacs has a mode for everything:
The mostly-single-threaded nature of Emacs gets in the way sometimes.
Jetbrains suite of IDEs are basically long tails and they have huge utility in many areas that exceed other editors.
With good "plugins" or "features" all of these things happen async.
Additionally installing these features on vim is a nightmare for various reasons. It can be done, and I've done it, but the experience is not as good as the more clunkier GUI IDEs. I'm all for a TUI IDE if the experience was as automated or seamless as jetbrains or M$, but such a app doesn't exist yet.
Sometimes, but with single powerful IDE solutions from companies like jetbrains, setting up a "cushy" environment is barely any work.
>Sometimes that means driving somewhere and working through at 9600 baud over an RS-232 cable. Do this a couple times and you'll find that vi is quite usable--you just have to want it to be.
Of course if your network connections completely fail you have to use the serial console to fix it. There's no going around that. But the majority of developers don't even need to do this or don't even know what you're talking about as they only interact with cloud services nowadays.
Additionally a "cushy" environment doesn't preclude you from using serial console or using vim to do edits everywhere. VI in this sense is barely useable, it's basically the baseline necessity. You need it when all else fails. But it's not good to have it as your daily driver.
I promise, installing a Jetbrains product on a traffic controller (which is what I was thinking of re: the field trip) would be a tremendous amount of work.
> The majority of developers don't even need to do this or don't even know what you're talking about as they only interact with cloud services nowadays.
Yes, and they're one geomagnetic storm away from being entirely useless. It might not be for everybody, but there's value in being able to work with a lean toolset.
Jetbrains isn't installed on a traffic controller. It's installed on your local machine. Both VSCode and jetbrains have something called "remote development" which allow you to develop on a remote machine as if it was local. It's similar to ssh and vim.
>Yes, and they're one geomagnetic storm away from being entirely useless. It might not be for everybody, but there's value in being able to work with a lean toolset.
A geomagnetic storm will render everything useless, I don't see how a vim user will be more protected then a vscode user.
Editors are irrelevant to that conversation, but people who are accustomed to relying on stacks with many dependencies will definitely find that they struggle more without the internet than people who keep their dependencies minimal. And it's not a cherry picked example, there are all kinds of cases where minimal dependencies = resilience. It doesn't mean you have to go around using punch cards or something, it's really just the emotional attachment to complex tooling that I'm calling out as a hazard here. You end up cultivating skills that are easily invalidated.
You can remote ssh into the pi with Vscode or a jetbrains IDE with a laptop that likely won't be fried either under your description.
Python can run on the rasperry pi. Even high level interfaces will remain. Additionally GUI support exists on a Pi.