Hacker News Reader

Comment by ezekiel68 | Hacker News Reader

I was thinking there might be something interesting here. Then I got to this line:

  "I started a new job working on a large typescript React project. Vim couldn’t handle opening a TSX file larger than 50 lines without crashing."

And I was like LOL WUT? The author's case in this regard woudl be stronger if they helped us understand what was actually going wrong. Bad plugins? Conflicting macros? I'm pretty sure that simply opening a 50 line TSX file does not normally crash vim.

View on HN

Right, The point was about configuration. I had a configuration that worked for a couple years, then I start a new job and the config breaks on the first 50+ line TSX file. Now I have to go and find the culprit, find a replacement plugin (in this case, yajs JS parser was slowing things down). and before I knew it, I was re-configuring everything again. I was more criticizing the ecosystem of plugins and how brittle some may be.

That's definitely a huge issue. I've had the same experience of having to spend hours to a day getting my configuration set up for a new language. I think part of the problem is that there's no basic config for a language (as with other editors) from which users can tweak, mostly because anyone who tried to get vim users to standardize on any defaults other than those shipping with vim itself would be strung up and horse-whipped as a purveyor of bloat. Vim is a great editor and I love using it, but many community members have a "leet" attitude that discourages new users who need help.

It would be a whole lot easier if someone put together a set of basic configs for various languages that had language servers, completion, etc. and everyone referred new people to those. It's much easier to tweak and replace stuff than to assemble an entire config wholesale.

I was using ALE for autocompletion and such, but having switched to COC, I find its support for TypeScript to be far superior.

This is relevant because COC is basically a system for talking to language servers.

https://github.com/neoclide/coc.nvim

Yep, I too have switched to it and pair it with CCLS for my C/C++ development. It works great after learning it and does significantly reduce the overhead needed for new languages. It's a little tricky to set up for new users, but it's nice that things have improved so much.

Well, the thing about Vim and Emacs is that the users are expected to figure out configuration problems like these. That's not a point in favor of Vim and Emacs.

Right -- the argument here isn't against Vim per-se, but the entire ecosystem of plugins and configuration that's needed to work and be productive.

Sure, there are a bunch of choices for you to use... but now you have another problem -- there are a bunch of choices.

Exactly. If you argue the pros of vim/emacs using the power that comes with access to extensibility functionalities, it seems intellectually hishonest to not consider the ecosystem and customization issues also for the cons.

Well, some mixed feelings on whether or not it's a point in favor or not. Just like any system, don't install plugins/copy+paste config that you don't understand or can't maintain. I've been able to open tsx files with linting/highlighting/testing plugins and everything works as expected.

On the flip side, if you want easy configuration, then yes, vim/emacs/similar are not necessarily the right choices for you, but I don't think that means they are generally bad options.

> Just like any system, don't install plugins/copy+paste config that you don't understand or can't maintain.

I don't think this advice makes sense at all. I can't maintain cc-mode and I don't understand how it works, yet I rely on it.

Users should not be expected to understand how the TypeScript autocompletion works in order to get it working. I can open VS Code on a TypeScript project and get autocompletion working just based on the tsconfig.json, much of the time.

Oh, I don't mean like you could maintain the library, just the configuration it may expect you to provide it.

agreed 100%.

libraries live or die based on their interface.

I guess it really depends on where you want to spend your time. Time spent customising and tweaking my tooling is time not spent focusing on my core work.

Hence why, despite my interest in Fish, I'm still just making do with Bash, I just can't justify the time to make a proper switch.

> Bad plugins? Conflicting macros? I'm pretty sure that simply opening a 50 line TSX file does not normally crash vim.

These are not questions I've ever had to ask myself in the ~8 years I've been using IntelliJ IDEs for coding full-time.

Maybe it's easy to fix vim in this case, but it's really annoying to constantly have to Google your problem, find a fix, test out new configs, etc.

I left Linux after 20 years for the same reason. I'm happy to pay a small amount to have highly-paid software teams figure these things out for me.

Indeed, I routinely edit files in vim that are many GBs in size.

Note that you can still use <favoritesmalleditor> for those big files and the IDE for all the rest. I am using emacs with IntelliJ Idea (one shortcut or action to open current file or selected file in the file list if you don't want to open it in IntelliJ) . I'm using that when I need to edit orgmode files or do complex text processing on a file.

Reply on news.ycombinator.com