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

121–130 of 203 posts

Re: The State of Vim

#121

Post by ookdatnog »

sevensor wrote: post #103
ookdatnog wrote: post #56

Earlier quoted context omitted.

I'm sticking with emacs for now because it is the only editor I have encountered that actually works well in conjunction with a tiling window manager; by which I mean: it works well as a single process accessed through multiple windows (here I mean "windows" as in OS windows -- internally Emacs calls this "frames") although it has features for managing panes internally, it doesn't insist that you use them and each wi…

Kakoune does this too, and it’s amazing with a tiling window manager. On a big monitor, I can get 4-5 terminal emulators across, and in any of them, at any time, I can attach a kakoune client, copy and paste between buffers in different windows, edit the same file in two places at the same time, close all the clients and reattach later, and so on. Emacs is the only other editor that does this, as far as I know.

Thanks, I might give that a try :)

Re: The State of Vim

#122

Post by sodapopcan »

jitl wrote: post #115
wruza wrote: post #70

Earlier quoted context omitted.

Neovim turned itself into a pop-blink IDE which some people never wanted. It's good that it serves the needs of its fans, but it's also good that Vim stayed in its own tracks. Losing Vim as it is would be a great loss for many.

With no config file Neovim is just vim but with mouse mode enabled by default. With Lua and the new APIs it’s much easier to write powerful plugins that do crazy shit and use animation but none of that happens by default, you need to go out of your way to get that kind of action, same as with regular vim.

It's not, though. A bunch has been stripped out (interactive :!, :view, etc) and time only time will tell how much further they will drift apart.

Re: The State of Vim

#123

Post by w0m »

johnnyanmac wrote: post #55
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)

It's the best, when you find one. But the approach is also the riskiest. You may not even pick a BDFL to begin with (I'm sure many of us can name certain repos overly held back by a bad or muddy vision, or being overly conservative with feature/pull requests) . or that B fades away for any number of factors. Committees sacrifice that cohesive vision and agility for being able to have some checks to potential rouge ac…

> But the approach is also the riskiest

Honestly in open source I'd argue it's not. If an OSS project has significant usage, if BDFL struggles/etc - community forks can put the project back on pace. NeoVim is the classic (successful) example that gave us a great alternative while also nudging the BDFL into the modern age.

Re: The State of Vim

#124

Post by giancarlostoro »

cassepipe wrote: post #119

I had a easy to maintain, easy to understand vim + ALE + Gutentags + ... setup for C/C++ development and it worked very well but when I got into webdev I just gave up and jump to a neovim distribution as I was not able to catch up. So in the end neovim got me not because it is technically superior but because the community created distributions, which I am very grateful for (R.I.P Lunarvim) EDIT: Ok, maybe the reason…

I assume slowly over time Neovim will just win over vim because of this. I do want to say its much more capable than the original vim, I don't know that vim has a headless mode or that it intends on it, but Neovim has that, plus it can essentially let you write plugins in any language with its plugin RPC protocol. So if you want a plugin that targets your language you can leverage existing libraries that directly support your language instead of writing it all from scratch in Vimscript.

Re: The State of Vim

#125

Post by giancarlostoro »

flohofwoe wrote: post #29
eviks wrote: post #12

Earlier quoted context omitted.

that'd be the wrong lesson to extend a period of using a bad governance model for longer

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 the BDFL is a complete ass of course.

I think in the case of Linus, you REALLY have to be strict. I mean, its arguably one of if not the most used pieces of software deployed in enterprise and globally for all manner of use cases.

Re: The State of Vim

#126

Post by lynndotpy »

112233 wrote: post #46
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 origin…

This was my experience. Couldn't get into Vim, and once so got used to Neovim it broke. :(

I really love the Helix editor, and haven't had these issues yet, but it's not intended as a 1-1 vim replacement.

Re: The State of Vim

#127

Post by giancarlostoro »

johnnyanmac wrote: post #55
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)

It's the best, when you find one. But the approach is also the riskiest. You may not even pick a BDFL to begin with (I'm sure many of us can name certain repos overly held back by a bad or muddy vision, or being overly conservative with feature/pull requests) . or that B fades away for any number of factors. Committees sacrifice that cohesive vision and agility for being able to have some checks to potential rouge ac…

> or being overly conservative with feature/pull requests

We saw some complaints about a repo like this I forget for what project some weeks back here on HN and it came down to, people dropping a PR and then the maintainer left holding the bag if something goes wrong, having to maintain someone else's code, which can become a problem if its a completely new feature they didn't implement or want, but users wanted. The other case is, they fix a bug, then disappear, so if the maintainer has feedback, now they have to take time to check out the person's code, update it, out of their current planned work.

I wonder if more open source projects would benefit from adding plugin architecture so people can do those one-off features as plugins without "tainting" the core project.

Re: The State of Vim

#128

Post by surajrmal »

ykonstant wrote: post #120

> How can we make Vim9 script, the new Vim scripting language, more widely used? One way is to inform users and prospective plugin writers that 1) Vim9 script is vastly superior to the old Vimscript, to the point where it is not unpleasant to use, and 2) it is much more conductive to writing text editor code than the general purpose Lua. Of course this still does not mean that people will want to learn yet another sc…

Honestly supporting a language is a lot of work. Documentation, language servers, ramping time for users to learn it, etc. I find it hard to believe vimscript9 is worth it over lua. I've seen the ecosystem for neovim seem to thrive, and in part because it looks like lua is a lower barrier language, especially if you've used it outside of vim.

Re: The State of Vim

#129

Post by ykonstant »

volemo wrote: post #25
krykp wrote: post #7

Earlier quoted context omitted.

With nvim, there has been quite the resurgence of Vim. Good software tends to be resilient. I believe both emacs and vim will see many, many more years.

I wonder, will there be something to emacs, as nvim is to vim?

Emacs seems to be a local maximum that is difficult to overcome. An entire Lisp Machine environment would be better, but it would be a tremendous undertaking and the specialists, i.e. emacs devs, don't seem to be interested in such a thing.

A multithreaded version of emacs would also be an interesting addition; I read some arguments against moving emacs to a multithreaded model, but I don't really remember them.

Re: The State of Vim

#130

Post by sodapopcan »

ykonstant wrote: post #120

> How can we make Vim9 script, the new Vim scripting language, more widely used? One way is to inform users and prospective plugin writers that 1) Vim9 script is vastly superior to the old Vimscript, to the point where it is not unpleasant to use, and 2) it is much more conductive to writing text editor code than the general purpose Lua. Of course this still does not mean that people will want to learn yet another sc…

> Of course this still does not mean that people will want to learn yet another scripting language

I understand this sentiment and that there are certainly psychological blockers in having to learn too many languages, but vim9 is very simple to learn. It is much closer to a "familiar" language than Lua. Plus, you are going to have to be familiar with Vim's standard library anyway. I believe they are adding more and more helper functions but Lua plugins are full of `vim.cmd` and `vim.fn`. I don't dislike Lua as a language at all, but I much prefer "scripting Vim" in some sort of "VimScript" :) But to each their own.

Post reply on HN