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

“Unusable without any plugins” is quite a description to throw in there as an assumption.

It's barely useable. I rely a lot on code completion, search capabilities and syntax checking while I code. It just saves a lot of time from having to execute the compiler and wait for it to check everything.

With good "plugins" or "features" all of these things happen async.

Like Godwin's Law, every discussion of Vim on HN will inevitably tend towards complaining that it doesn't have features that it has shipped with 10-30 years.

It doesn't have code completion. You can install it as a feature, but vim itself doesn't have that feature. There needs to be a law for someone either flat out lying or not knowing what they're talking about because godwin's law doesn't apply here.

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.

^n

That’s your preference, which is fine. I started using extensions earlier this year, they were a little annoying to set up and don’t add much, I probably won’t do it again if I change machines.

Sometimes it's faster to fix the code where the bug is, rather than trying to recreate it in your cushy dev environment. 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.

>Sometimes it's faster to fix the code where the bug is, rather than trying to recreate it in your cushy dev environment

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.

> Sometimes, but with single powerful IDE solutions from companies like jetbrains, setting up a "cushy" environment is barely any work.

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.

>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.

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.

>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.

Not everything, just things hooked up to long enough wires to induce significant current. Pretty much just the power grid and the copper communication networks. For instance, I've got a raspberry pi hooked up to some solar panels handling some gardening stuff for me, it'll be just fine.

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.

>For instance, I've got a raspberry pi hooked up to some solar panels handling some gardening stuff for me, it'll be just fine.

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.

I'm aware of these features. I've used them in pycharm and intellij and vscode. I just find that they're a bit much to keep track of, and aren't usually worth it. I don't need a development focused OS in my OS, I have Linux for that.

It's been VSciode lately, and it's infuriating how it wants to handle everything for you. You can't just configure your linter, you have to do that and then figure out how to trick VSCode into invoking its linter in a way that respects the same configs otherwise CI won't agree with the dev experience--to name just one case of overreach.

And it's always guiding me to install this plugin or that widget and it's like:

> Great, now I'm relying on all of these undeclared dependencies and I don't know what kind of hell I'm creating for my PyCharm colleagues.

There's just a whole pile of problems that just don't come up if you let separate tools be separate tools.

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)

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.

Vim is not an "app".

I was drawn to helix specifically because it is excellent without the need for plugins.

LSP and tree-sitter grammars carry so many of the features I had to add to vim and emacs—over years of configuring—that I feel like I’m not missing anything important; despite having an emacs config large enough to justify its own repo outside all my other dotfiles.

My whole helix config is telling helix what theme I want and the path to my nix formatter, and it feels nice.

Your points concern everything around text editing, but not editing itself. Emacs brings nothing new to the table with respect to editing model, it's essentially notepad (with different interface, plugins, yada yada yada — all the things you mention). Vim has a model with modal editing, much better than Emacs. Kakoune and Helix improve this model even further.

It's like comparing cars by the color of the trim and air conditioning, instead of… er… their car performance (power, speed, fuel usage, durability).

If you don't care about editing models, and just want to "type code", then Vim is hardly the best choice. Emacs and Intellij are much better than Vim at plugins, and are as available as anything else.

> Emacs brings nothing new to the table with respect to editing model, it's essentially notepad

Emacs (1976) predates Notepad (1983).

I do understand what you mean, though. For people using Windows, Emacs needs to be sought out and installed, this effort needs to be justified (assuming one is permitted to install software at all), and hence the requirement for Emacs to "bring something new to the table" over the default option, Notepad, which is just /already there/.

The most basic, implicit, requirement, then, is exactly as GP says: availability. All else follows.

I meant Notepad as an example of something that implements the basic "move the cursor between the characters with arrow keys and type to insert text" way of interacting with text. In terms of this, Emacs is exactly Notepad + plugins. And plugins (unless they drastically change the way you interact with text, like Evil mode) are usually doing something that is orthogonal to the editing model, and can be slapped on top of any editor with any model.

I didn't mean that one is based on the other historically. Notepad was meant as the most minimal example that implements one of the Emacs'es aspects.

Chordal editing isn't as popular as modal editing, but I do like it and think it's something uncommon in other editors, at least to the same extant as emacs.

The thing I like about emacs is the integration and consistent experience. I can do everything in emacs (and use exwm as my window manager), so I have the same keybindings for everything.

As perhaps an extreme example, imagine having 1. A window manager like i3 2. tmux or screen 3. (n)vim or helix sessions with edited files, possibly inside tmux/screen

Each of these need to be configured separately, and each layer needs different keybindings so that uncaught ones can be forwarded from one layer to the next. Each layer is limited to only the subset of things it manages. E.g., i3 can let you switch between firefox and the terminal running tmux, but not the different sessions tmux manages, or views of any of the files in your nvim session. Etc.

Or I could just use emacs create tiles I can move between, and each of which that is capable of opening any of my x-windows, terminal sessions, or open files. You can even use the same autocomplete in your shell as when editing files.

I don't know of anything that gives the same simple, unified, workflow of EXWM (+ corfu&consult&...). It does have issues and could use a serious modernization -- still single threaded in 2023, with some commands blocking IO??? -- but perhaps it's simply much too ambitious for someone to try and make a competitor. These can have modal editing, tree sitter and lsp integration would be great, etc. The thing I want is the smooth integration of everything I may do on a computer into one interface that emacs, but no other software I'm aware of, offers.

What is chordal editing? Google search didn't give me any results.

I agree that having different programs on you computer integrated and consistent is a good thing. Sorry for the reference to the old joke, but wouldn't all the things you list look better in a wishlist for an operating system instead of a text editor?

By chordal editing, I just meant pressing combinations of keys at the same time. Lots of editors support this to some degree, but most (AFAIK) are either modal, or don't support keyboard-driven workflows. One of the other classic emacs jokes is about how it can take key-combinations to extremes, e.g. https://xkcd.com/378/

I agree that I'm looking for a tiling window manager. This is what EXWM (the Emacs X Window Manager) is. The problem with things like i3, is that it is not integrated enough with editing and navigation of files.

I wish there was more in this space, as Emacs has some limitations for this purpose (e.g. multithreading), but AFAIK emacs stands alone.

> Emacs brings nothing new to the table with respect to editing model, it's essentially notepad

Wow, and here I thought I had seen all derogatives about Emacs ;-) But claiming that it doesn't bring anything new compared to Notepad is really strange.

1. Emacs predates Notepad by one or two decades. 2. Have you actually had a look at what is actually included in Emacs? I am not talking about mail readers and other "apps" inside emacs. I mean just for editing text in a non-mode specific way. Things like rectangular cut and paste, vertically aligning stuff, infinite undo, undo restricted to the selection (region) and many many more stuff. That Notepad doesn't have.

> Have you actually had a look at what is actually included in Emacs?

Yes, I've been using it for a few years and made my own plugin with a couple dozen users. Then I discovered Vim overnight and never used Emacs again (literally).

> But claiming that it doesn't bring anything new compared to Notepad is really strange

It does indeed sound strange because you missed the "with respect to editing model" which is crucial for my point. Emacs has nothing in it other than Notepad + a large number of ad-hoc, non-coposable plugins each doing one task.

> Things like rectangular cut and paste, vertically aligning stuff

Ad-hoc things that do only one very specific task each. Incomparable to Kakoune's powerful and composable way of interacting with text.

> infinite undo, undo restricted to the selection (region)

Orthogonal to the editing model. These can be slapped on top of any text editor, be it vim or notepad. Just make a plugin.