Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The State of Vim

lwn.net

Post reply on HN
Print view View original

41–50 of 203 posts

Re: The State of Vim

#41

Post by eviks »

bawolff wrote: post #36
eviks wrote: post #31

Earlier quoted context omitted.

Saying "no" is the easiest job in the world, and committees are pretty good at it. That's why we have decades-old design failures everywhere, because saying "no" to an improvement is so much easier that doing the actual governing and resource allocation to see it through, especially with volunteers And given the article describes big fails at basically every aspect of project management (from github account to money…

There are two types of comittees: Those that are paralyzed by fear of change and say no to everything, and those that are afraid of offending people and say yes to everything. Both are counterproductive.

Reality is not binary, so this extreme simplification is counterproductive when describing one

Re: The State of Vim

#42

Post by weinzierl »

"DNS was also troublesome—the vim.org domain was managed by Stefan Zehl"

vim.org was created (probably around 1998) and has been owned by Sven Guckes for most of its existence. In the beginning Sven also managed the content but I think at some point Bram took over. Unfortunately Sven passed away not long before Bram.

Re: The State of Vim

#43

Post by dsign »

The aggregate value of each soul that goes away is staggering. Bram is a good example; his work in VIM and his help to children in need will be sorely missed. I wish we were doing more to break that cycle.

Re: The State of Vim

#44

Post by qazxcvbnm »

Ferret7446 wrote: post #20
dmortin wrote: post #4

I wonder how long vim and emacs can stay vibrant. I've used emacs in the last 20 years, so I stick with it, but new generations who are trained on vscode and such are less likely to use such "old fashioned" tools. Surely, there will still be emacs and vim users 50 years from now, but the user numbers and the community power will diminish as the graybeards gradually leave this plane.

You can't really compare vim and emacs beyond a superficial level. Emacs is fundamentally an interactive shell, like Bash. It has a text editor, also like Bash. It is of course generally more powerful and featureful than Bash. Hence, people sometimes live in Emacs, because it's a shell like Bash or Gnome or KDE. I use Emacs and VSCode. VSCode for some code repos, and Emacs for general computer usage. Meanwhile, Vim i…

Just for the other side of the picture, I live in vim and use it as my terminal multiplexer. Vim’s my shell. I have thousands of buffers in vim and practically never leave it. I’ve used terminal multiplexers for years before I switched to vim in that capacity and never looked back. The integration it’s allowed between all my buffers and commands and shells is difficult to match in my opinion.

Re: The State of Vim

#45

Post by camgunz »

eviks wrote: post #31
flohofwoe wrote: post #29

Earlier quoted context omitted.

You need someone to say 'no' to all the stupid ideas, and also to the occasional good idea to stay focused. Committees and communities are quite bad at that. IME the BDFL model has mostly worked best for open source software development, unless the BDFL is a complete ass of course. (also software projects don't need to be democracies, e.g. people won't starve or sent to the gulag if things go sideways)

Saying "no" is the easiest job in the world, and committees are pretty good at it. That's why we have decades-old design failures everywhere, because saying "no" to an improvement is so much easier that doing the actual governing and resource allocation to see it through, especially with volunteers And given the article describes big fails at basically every aspect of project management (from github account to money…

> Saying "no" is the easiest job in the world

It depends on your motivation. Probably a lot (many, most?) committees can just sit pretty and try to do as little as possible. But a lot of software projects exist by getting attention, and they tend to do that by adding features. A lot of FOSS maintainers find it super hard to say no. For some anecdata: I have a small/medium project and I've found that just the energy requirements of really thinking about everything everybody proposes are pretty high. I could just say "yes", but then I'm on the hook. I could also just say "no", but then I'm discouraging people and not really giving them any information about how to contribute productively--this would be something like, "sure we could add a flag to turn video upside down, but I'm concerned that putting this kind of functionality in flags means we'll have a UX of 1000 flags that no one can remember or use; should we start considering building another place to put this kind of functionality?

Re: The State of Vim

#46

Post by 112233 »

porphyra wrote: post #11

Many of the Vim nerds I know, including myself, have switched over to Neovim. Only when using a remote server with a default installation do I use regular old Vim.

Neovim sounded like a good idea, so I switched, too. Then after an update, it broke mouse selection in terminal, by turning on some crazy option by default. I still have to search how to disable it each time. Ok, things like that happen. Then, after another update, it broke terminal update. Like, your screen scrolls up or down a line and the text does not get redrawn correctly. Is it a wezterm issue? Well, the original vim works flawlessly. So do less, top, and any other terminal programs. Except neovim.

No thanks. I dont care how many golden elephants are in the trunk if I cannot drive it.

Re: The State of Vim

#47

Post by dailykoder »

xarope wrote: post #16
atorodius wrote: post #13

Earlier quoted context omitted.

I use VIM bindings in VS Code. Always assumed many do but might be wrong

Ditto. I went from vim to neovim, but the LSPs for python/go(lang) for large files (not that large, maybe 10k loc) seem to really bog it down (back then, no idea if it's better now), whereas with VS Code it was still performant enough. So I ended up using VS Code with Vim bindings. And yes, with ad hoc work, I still end up using system vim when just doing simple edits (e.g. adding a line to README.md or somesuch)

At work I often switched to VSCode because I couldn't get pyright to work with our django project. The errors everywhere were just annoying to look at. So I looked around and found "ruff" and "jedi_language_server". This combination seems to do the trick. I don't have to configure anything. I source my venv and it "just works". I assume our python codebase is something around the 10k LOC, too. I am not mainly responsible for the python part, so I don't spent excessive amount of time in there, but for the time I do, it works nicely

- https://github.com/pappasam/jedi-language-server

- https://github.com/astral-sh/ruff

Re: The State of Vim

#48

Post by makeitshine »

dmortin wrote: post #4

I wonder how long vim and emacs can stay vibrant. I've used emacs in the last 20 years, so I stick with it, but new generations who are trained on vscode and such are less likely to use such "old fashioned" tools. Surely, there will still be emacs and vim users 50 years from now, but the user numbers and the community power will diminish as the graybeards gradually leave this plane.

Vim may die, but vim-mode will definitely be around.

Re: The State of Vim

#49

Post by joelthelion »

dmortin wrote: post #4

I wonder how long vim and emacs can stay vibrant. I've used emacs in the last 20 years, so I stick with it, but new generations who are trained on vscode and such are less likely to use such "old fashioned" tools. Surely, there will still be emacs and vim users 50 years from now, but the user numbers and the community power will diminish as the graybeards gradually leave this plane.

To me, vscode is unbearably slow. I think that alone is enough to keep vim alive.

Also, I don't really miss anything from more advanced ides when in vim. There are great packages for almost anything.

Re: The State of Vim

#50

Post by fsloth »

psychoslave wrote: post #34
flohofwoe wrote: post #29

Earlier quoted context omitted.

You need someone to say 'no' to all the stupid ideas, and also to the occasional good idea to stay focused. Committees and communities are quite bad at that. IME the BDFL model has mostly worked best for open source software development, unless the BDFL is a complete ass of course. (also software projects don't need to be democracies, e.g. people won't starve or sent to the gulag if things go sideways)

Unless your software deals with tracking people within an organization that will of course comply with the political parties that rule the regions where there software operate.

If Vim tracks you then that’s a willfull act that breaches trust.

IMO no governance model can defend against supply chain attacks.

IMO you shouldn’t try to fix things with governance model which it doesn’t fix. Use a governance model that leads to good governance. In technical and creative work single highest point of authority is best.

Not because they have perfect knowledge or are the best but because dictator led models lead to best alignment - which is something you simply need to execute when performing a complex task with many stakeholders.

Dictator led models aren’t best for everything. But for complex tasks with specific fixed scope with multiple concurrent contributors it seems to be the only model that works (if there are case studies as counter example I would love read on them! I.e. complex task, more than 10 contributors, non-dictator governance).

Post reply on HN