> A common selling point for VIM is "its installed everywhere you just ssh in and it's available".
I've never understood this argument unless you're coming at it from a sysadmin perspective. Sure if its available everywhere that helps when I'm sshing in to random systems to sysadmin stuff.
But I don't do my development by logging in to random new systems all the time. I do my development in an environment that I have set up to be productive with.
That’s a very specific development story, though, common to e.g. web development.
If you’re, for example, a developer working on an embedded platform which (even temporarily) has no ssh, and probably no emacs as well, tramp-mode won’t work.
I’m a hard emacser, but it’s true that vi is usually much more ubiquitously available, so it’s good to know how to use it.
SSH isn't the only protocol supported by Tramp (from what I hear, it's actually a late addition). Essentially, if you can get somehow get a shell on a remote machine, you can make Tramp work with it.
It might be possible to get tramp working over a serial line (while still being able to use the same shell, though?), or over telnet, but practically I'd probably just type "vi" to quickly edit a file.
Again, I'm saying that as someone who uses tramp-mode all the time, otherwise.
> If you’re, for example, a developer working on an embedded platform which (even temporarily) has no ssh, and probably no emacs as well, tramp-mode won’t work.
Maybe I'm wrong but I really don't think embedded developers do a lot of work directly on platforms that low level/limited.
You do your development on your main machine, automate deployment to your target, and debug using a gdb server or openocd.
Honestly mg or nano is more ubiquitous than vi. Any system that has vi installed will likely have nano as well.
As an OS developer myself, I can tell you that logging into platforms to quickly tweak something using vi happens all the time. It's not about "directly developing" on the platforms, it's about debugging and trying things out.
nano is a very young editor, comparably, invented in 1999, and GPL on top of that. I'm not sure it even come out of the box with any of the BSDs (OpenBSD at least does not seem to have it).
vi was first written by Bill Joy himself in 1976, and I'm pretty sure it proliferated in many different forms over many, many different platforms.
This really hits at a core of what I call developer vs. sysadmin perspective. A developer usually works in a persistent environment they fully control. A sysadmin does a lot of work on multiple, often short-lived servers. So the former prefers customizing things the way they like; the latter learns and sticks to defaults.
At one of the Lisp projects I worked on, this split was clearly visible. One of my co-workers had the dev perspective, the other had the sysadmin view. Both used Emacs and Slime, but one had it fully customized, and other had it bare-bones, and spent most of his time in raw terminal anyway.
(I, of course, am hard down on developer view. My Emacs config has no peers :)).
I've never understood this argument unless you're coming at it from a sysadmin perspective. Sure if its available everywhere that helps when I'm sshing in to random systems to sysadmin stuff.
But I don't do my development by logging in to random new systems all the time. I do my development in an environment that I have set up to be productive with.