As Vim9 comes alive, and Neovim community focuses on Lua plugins instead, it seems this release is finally the update that will put a hard branch on the two communities. Up until now, most plugins (except Lua-only ones of course) have worked in both editors, but it doesn't seem like Vim9 will be supported in Neovim, so I guess what people go with now, will decide what you might stick with in the future (unless you're eager to switch development environments).
Although I am currently tip-toeing on NeoVim, I still feel this is a horrible break-up.
Yes, Open Source simply allows you to branch whenever you're unhappy with the original but this comes at a cost for the community. The cost of having two diverging programs to deal with.
In this case, the motivation was simply insufficient. Some people wanted vimscript+lua instead of vimscript. They felt the code was too difficult. They wanted to develop on their own.
Not bad reasons in itself, but does it weigh against the tremendous cost for the community of the split? Isn't a split only justified in situation like OpenOffice/LibreOffice when there is no other choice? Couldn't they not convince Bram Moolenaar of proposed changes, and if not, doesn't this have a good reason.
I hate NeoVim for the reason they've split, even though I understand it might become even better than Vim in the long run. You need better reasons to fork and divide an ecosystem.
I think Neovim had a whole bunch of other reasons to split. I'm pretty sure that Neovim's server mode, which allows it to be used with other editor frontends, is simply not present in vim. For me this is the whole reason to use Neovim. But I think it also natively supports tree sitter and/or LSPs, which really improve the coding experience.
Anyway iirc Neovim wanted these features integrated into Vim itself and only started a separate project when it became clear that that wasn't going to happen. My understanding was that at the time Bram was hostile to lots of the changes that people wanted integrated. You can read some of the discussion [here](https://news.ycombinator.com/item?id=14245705) and [here](https://news.ycombinator.com/item?id=7287668)
And when Bram did finally add async support rather than take the neovim work and us that he did it in a specifically non compatible way. I don't know the ins and outs but as an observer that does come across as a little petty.
I just checked the repo[0], and it says Bram has authored 95% of all commits to Vim. To say "the community owns Vim" when they've done ~5% of the work reminds me of group projects in school where one person does all the work and everyone else claims credit.
For a while Bram would copy paste all proposed changes from other peoples branches to his own branches and therefore giving himself the git-blame for the code. I think only recently he started allowing other people to actually maintain the repo.
I'm not sure this is because no one wants to contribute. I think it's more because Moolenar prefers to do the work himself, and doesn't like to accept much in the way of contributions from others. He's certainly allowed to run his project that way, but I can see why it might turn some people off.
Which is yet again contrasted with how NeoVim runs things and the 824 contributors to the repository at time of writing. I believe that justinmk, one of the principal drivers of the project specifically stated that he doesn't want to be something like a BDFL and I assume that's also pretty much a reaction to Vim.
One is not a better parent by controlling their kids for their foreseeable future. One needs to let them join the world and grow on their own, with their own friends.
It’s true that anyone can fork the code. But splitting the user community and plugin ecosystem with forks should be a last resort. This discussion is about how a FOSS community can improve software while avoiding forks that result in incompatible code-bases.
We're used to open projects but Bram's seems to be that he wants to be in control, he's the main author. So Vim is then open source but not a completely open project.
That's pithy but a characterisation that misses many important aspects.
Bram's been developing Vim for 30 years [0]. Just think about that for a second. An open source project that's been running for longer than the age of probably 50% of the readership on hackers news. It's ways of working and values have been developed over a long period of time.
Vim favours being available on multiple platforms, alignment with Unix tradition and stability:
> Vim is a highly configurable text editor built to enable efficient text editing. It is an improved version of the vi editor distributed with most UNIX systems. (https://www.vim.org/about.php)
Neovim is built by people who value fullness of features, who see multi-platform as 'legacy platforms' and are happy to break backwards compatiblity for the value of making something more complete by contemporary standards.
The easiest summary is - Bram's comparison is Vi, Neovim teams' comparison is VS Code.
I love many of the NeoVim's new features and capabilities.
But, I think it's possible to like Neovim while also understanding the positive value of Vim and why their approach is different. There's something in the human condition about turning everything into a winner and loser, a hero or a villain - but it's just not true.
As a project that's been running for 30 years Bram and that community have an approach that they are comfortable with. There's a way of working, and a rhythm to the project that has worked over the long-term. They're evaluation of changes is against their own internal values - those values are different to the people that are working on Neovim. Personally, to me 30 years of effort and contribution to providing something totally free is unbelievable.
vim's support for legacy platforms is... IMNSHO extreme to the point of self-harm.
many of the systems it supports haven't received updates in decades and have essentially no users. The old versions work just fine on them, and require no changes because those systems aren't changing. There's no reason why _new_ versions of vim have to be held back by the need to work on ancient platforms.
I think it's fair that a new person is needed at the helm to want to look forward to new features. A comparison with Vi only means the status quo is good enough. When we put it like this, Neovim is unavoidable. (The fork is unavoidable, but it doesn't mean the demise of the old project.)
I'm not even sure it's human nature to put it as winners and losers. Our current culture is obsessed with seeing it in this way, very much influenced by "the economy" of the wide-area societies we live in, but I'm not sure it's universal.
The success of Neovim is great example of the advantage of open source. When the developer of a popular piece of software didn't want to implement features some of it's users wanted, those users were able to fork it and create a successful project that had those features, and eventually led to more innovation in the original project.
The divergence and incompatibility is unfortunate though, especially since some of it just seems petty. Made moreso, because it isn't possible to truly polyfill functionality from one in the other (native commands and functions are effectively in a separate namespace than user-defined ones).
I think you mistake the parent's point. Vim's code is certainly open source (I don't think anyone disputes that), but its development model is not the one we've come to be comfortable with. Moolenar maintains an iron grip on vim, and controls what goes in (and what doesn't) much more strictly than many other open source projects. That is certainly his prerogative, but it's also the prerogative of others to not like that, and want to fork and create something that is more welcoming to outside contributions.
> the development model is not the one we've come to be comfortable with
Says who? There are many free software projects, with public source code and free licenses, that are not developed openly. For example, lua itself (on which neovim is based). The lua team are adamant on not accepting external patches. And that is perfectly alright, and not contradictory with neither the letter nor the spirit of free software.
> but its development model is not the one we've come to be comfortable with
"Open source not open contribution" is increasingly seen, and people don't seem to mind, and the attitude described with regard to vim development seem less "thanks, bit no thanks" than that, so I don't imagine any majority have an issue with it.
If I finally get around to making and releasing some stuff I plan, "not open contribution" is where I'll be. These things are my toys, they'll go my way, though the source is there so feel free to fork if you need/want something I'm not planning to do or not planning to do soon enough (I'll even link to your efforts so people wanting the same know where to find it). Unless you want to pay for my time to maintain and support your feature going forward, of course!
But "open project" is not a helpful term either, which can mean anything from an open-for-suggestion proprietary project to a maximally open project (whatever it means). The correct term would be "open governance". We perceive "open" as something positive, which is of course not always true and there are different kinds of "open".
Give a read to "The Cathedral and the Bazaar" and subsequent essay "Homesteading the Noosphere". They'll give an overview of different software designs, including the management of building those designs, in a open source/free software context.
Both development models are OK, and plenty of people are comfortable with both. I'd actually argue that most early/not-"modern" FOSS software have had the model of "you're welcome to contribute, but we ultimately own the codebase and therefore decides what goes in. If you're unhappy, feel free to fork", and it's not until lately, that some projects have decided to merge almost whatever people contribute.
Some projects even go as far as giving people direct write-access as soon as someone has got a PR merged, but I don't think that's very common, neither is the "merge without strict review" model you seem to referring to.
> In this case, the motivation was simply insufficient. Some people wanted vimscript+lua instead of vimscript. They felt the code was too difficult. They wanted to develop on their own.
> Couldn't they not convince Bram Moolenaar of proposed changes
I think (but someone correct me if I'm wrong) it started out with one of the persons who started Neovim, tried to get in a patch adding async support in Vim, but Moolenaar didn't want to merge it, for one or another reason.
That cascaded to a bunch of other reasons over time, like adding Lua support and trying to rely less on Vimscript.
But that's how I remember it being started at least, but I could remember it wrong.
My read of that thread was that the initial patch had a lot of issues. The design had some flaws. The patch lacked documentation. It was like they didn't read the contributing guide. Lots of bystanders threw a bunch of noise into an otherwise normal dev process. Bram and others had reservations. Bram made good faith efforts to help them evolve the patch through iterative feedback. There was an early hint of incompatible development styles (emphasis mine):
You are correct in that we added a timer to the main loop. Looking over the code once again, I think we should have altered the calls to select/poll instead, but lets discuss the practical effect of this patch *since we can work out the details some time later.*
The vim dev process does tend to be slower than a lot of other open source projects. That is frustrating for some people but the model has proved remarkably sustainable. After about 1.5 months one of the authors said:
Bram,
I happy to see there is still some hope for this patch getting merged.
Then shortly afterward the other author gave Bram an ultimatum:
Thanks for taking time to look at our patch and give feedback. Besides pausing/resuming timers, are there any other blockers for merging this patch? Matt and I really want to get it merged, but there's been a recurring pattern where we address one thing only to have another brought up.
If this is the last thing, we'll gladly add it. If it's not the last thing, please give us a complete list of blockers. Then we can determine if we want to continue addressing your issues or just maintain our own fork of Vim.
Considering where the patch started, iterative feedback seems appropriate.
Bram replied (in part):
It's better to postpone including this patch until we settle down on how it works. I have had bad experiences with including a feature before it's fully working or insufficiently tested.
The patch authors never replied. They may develop under aliases but I've never seen either of their handles in the neovim commit history.
As someone who has engaged in the vim dev process and experienced each of the things the authors of this patch experienced, my conclusion is that they came in with fairly unreasonable expectations. They seemed to have financial interests pressuring them to cap the investment they were willing to make in the process. It's worth noting that a few years later Bram came back to the notes he made from that thread and solicited feedback (https://groups.google.com/g/vim_dev/c/M1mJ1qHHr40/m/Hd7UHMe3...) re: how timers would be used. Without the noise and suggestions to merge-now-fix-later the process went quite smoothly and the landed on a reasonable implementation that AFAICT would have solved the original need. Far from the "apathetic" epithet spawned by that 2013 thread.
I caution anyone reading this to not take this summary at face value. If you're interested, you should read the linked threads for yourself. I'd say you can leave out that someone followed up on some technical detail three years later, but you be the judge.
FWIW, my takeaway was the exact opposite. How the original async authors were treated was a disgrace. It showed, to me, that there were deep problems with the vim dev community. Forking off neovim was the best thing that could happen. I'm so glad someone had the energy to do so.
That said, I'm super grateful for Brams work on vim. It was my tool of choice for many years.
He had a separate interest in async but never actually asked for anything to be merged. You'll notice that it is advertised by Thiago as a proof of concept. One of the authors of the previous patch showed up to give a fairly inaccurate summarize of the previous thread, seemingly attempting to dissuade Thiago from continuing. The characterization of Thiago trying to get something added and being stymied seems to have come from the author of that original thread in a comment here:
In Thiago's words, the inspiration for forking seems to have come from the opportunities that were cataloged by Marc Weber. About two weeks after forking he did add the message_T changes to neovim. To say that his goal with that patch was simply to get async support into vim though is to disagree with Thiago's own words on the thread. He was upfront that he wanted to refactor the vim architecture around a different paradigm that he describes as a message loop.
Thanks for this. I had the same read when I read the original thread. The authors were lazy and kind of petty in their responses to Bram. Put me off the neovim project because it seemed the authors didn't care about design.
Weird, so people who give justification for neovim and use that thread are wrong. Thanks.
Speaking of message-loop design. This is a typical design in the vast majority of GUI software where the center of the program is a message loop. I never realized the original vim didn't have that kind of design. What is it's design?
It could be also argued that if Vim wanted to keep the community together they could have just deprecated vimscript and adopted Lua.
Of course I am stretching things a little, I know.
I personally think Neovim's reasons for a fork are valid. They wanted some parts, not others, and they were willing to pull the work. So a fork is made. That is all ok. If my memory serves both projects have interchanged patches and improvements in both directions, so everyone has benefitted in some ways. The community (communities) will live on.
Vim was stagnant until Neovim became a threat. And it was never about Lua. It was about the need for async. Bram ignored the community, and so the community responded, and made something better.
Neovim has already been very productive by giving Vim some good competition and in so doing having better features come out in Vim.
To me it doesn't make sense to 'hate' neovim for wanting to develop features that they tried to have in Vim but couldn't due to the main developer stalling it.
To me, vim has never been emacs. I run two plugins, vdebug and MRU (most recently used list... super useful). Everything else is out of the box. I like where neovim is going, I think it's great, but vim is fine for me.
async and embedded terminal were the original features neovim was created to realize; later, lua as the first class plugin language came in.
Underlying it all, though, was that vim has a bus factor of 1: Bram. Bram is the sole chokepoint through which all change flows, and thus holds back a lot of community dev. Neovim early on pursued a working model allowing for a larger community of interested devs to contribute, and it's paid off: the originator of neovim has moved on and a new steward has taken over smoothly, and they have around 30 core contributors.
So your anger at Neovim is misplaced. They created a modern vim open to many devs, and incidentally rekindled active work on vim, which had been stagnant before. You should be thanking them, even if you don't switch. You have async and terminals in vim because of them.
Stability, backwards compatibility and ubiquity are my reasons for using VIM so I neovim doesn't really offer much for me.
Yeah, I took a bit longer for async to land in VIM proper but how is that a problem? Isn't is good that Bram put his foot down and insisted to do it right-way instead of the fast way?
There is already enough "move fast and break things" software out there. I am happy for neovim and some innovations are interesting but for me the disadvantages of less stability are not worth it. I don't really see a need to increase the "bus factor". VIM is not a business, it can afford to move slowly but purposefully.
The problem, as perceived by the neovim creators, was that vim wasn't moving at all. It wouldn't have taken a bit longer; after their experience, they felt like async just wasn't on Bram's radar, and the maintenance model of vim was hostile to not-Brams. They needed to please Bram to get their patch in, and he spent months saying "fix this. Ok, now fix this. Now fix this." You can tell from Thiago's last message that he's come to believe they'll never get their patch accepted because there'll always be one more thing to fix because Bram doesn't want their patch.
Stability and backwards compatibility were built into neovim from day one. I used it from the 0.1 days, never had a crash, and all my vim plugins just worked. They put incredible effort into not breaking compatibility with existing vimscript, even as they constructed a new, modern build pipeline and development model, and refactored 30% of the code out. It wasn't until they added features of their own that full compatibility was lost because Bram wasn't interested in porting their work back to vim.
This really wasn't "move fast and break things". It was "vim development is stagnant, our only choice is a fork." And now Vim and Neovim are now vastly better pieces of software than Vim 7 was. Forking Vim did wonders for Vim itself.
> You can tell from Thiago's last message that he's come to believe they'll never get their patch accepted because there'll always be one more thing to fix because Bram doesn't want their patch.
This seems more like an inexperienced developer getting frustrated with the process. I absolutely would expect that new contributors will have to go through multiple revisions before they can get anything merged.
When I started working as a junior dev my first merge request had more comments from seniors requesting changes than lines of code. It can be absolutely brutal but that something everyone needs to go through.
If he had tried for years he might have had a point but just because it took months does not mean Bram was not interested in the patch at all. Otherwise he wouldn't have suggested any fixes.
Considering what Thiago accomplished by forking Neovim, you can’t describe him as an inexperienced developer. By all accounts the cleanup alone was was a huge and very successful effort—-from 300k LOC to 170,000, huge jump in test covereage, modern build chain and code checking with Coverity. He didn’t do it alone, but he led the effort and managed it incredibly well.
Seriously, you don’t have to love Neovim, but credit where it’s due.
I don't know if the "split" is justified, but "Some people wanted vimscript+lua instead of vimscript" is not an accurate description of the reasons for the existence of the neovim project. The goals and non-goals are stated clearly in the project charter: https://neovim.io/charter/.
The split of Vim and NeoVim was actually one of the reasons why I chose to switch to Emacs 2 years ago, after sticking with Vim for ~15 years.
Vim was great but the script language had always been too hard for me. NeoVim was getting a lot of development, but it was foreseeable that Vim & NeoVim would be completely incompatible someday, and I'd feel bad leaving the original Vim community for something that might eventually replace it. At that point I figured, if I have to switch, let's try something that's more stable and less likely to fork. Then I never looked back.
> Isn't a split only justified in situation like OpenOffice/LibreOffice when there is no other choice?
I think, the situations are incomparable. OpenOffice is effectively dead and should admit that, it's abandonware unlike Vim which is actively developed. Let all flowers blossom. Just remove dead ones from the garden. It's infuriating that OO insists they do something while they don't, best they can do now is to just put redirection to the LO site and move on.
lest us not forget the years of good hardwork of the openoffice patchset, i think it was called Go-OO that was basically a bunch of package maintainers trying to keep OO running. That became the eventual basis for LO.
My opinion must be marginal, but in my view neovim community took an IDE route anyway so maybe it is a good thing if they separate, provided there is a way to switch. Because when you have a function in bigpkg.tgz, no incentive exists to dedicate a smaller package to it, and that changes the entire landscape dramatically and may create political issues in it. I actually liked simple little plugins vim had back in the day and not these coc/lsp/ycm things which compete in size with the editor itself, if not outright an order of magnitude larger. I tried to go neovim at least three times and it seems to be focusing on these big things, while e.g. having long standing issues in gui functionality on windows, namely gui mode (qt-nvim) resizes, window updates, file associations. With vim9 I’ll maybe finally learn to script it as I wish.
One of the neovim devs released a video just a couple of days ago on the topic.
He suggests neovim (and vim, emacs etc) fall into a category between text editor and IDE.
The term he uses is PDE (personalised development environment). In short, you have lots of power to customise your setup; you can give it some IDE-like behaviour but the way you do it tends to be by making personal choices of plugins and config.
It's not just a text editor, it's definitely not 'integrated'. I'm inclined to agree with him.
That’s why I inserted “community” in the middle of that sentence. Neither of the mentioned plugins are neovim’s own, it only enabled their existence. Not sure why Bram was against “async”, but I am highly suspicious about this part.
IIRC one of the main reasons to split is because Vim is a one-person effort, they don't take PR and they didn't want the drastic change, so Neovim had to be a fork because there's no way to convince Vim author to take changes
That's not accurate. It's also pruning from the resulting list the commit authors for which GitHub is unable to associate a GitHub account with a given contributor; it simply doesn't attempt to represent contributors who are not (known) GitHub users.
(That isn't to say there's any significance here to Vim; the Vim repo does genuinely obscure patch authors by not using the appropriate fields to capture that information—most commits, going by Git metadata, are attributed to Bram using that method. But the statement "all GitHub's doing is looking at commit authors", strictly speaking, is not true.)
Well, the two projects don't follow the same development model so comparing (artificially capped) GitHub-centric lists is not exactly conclusive. One has to dig a little bit deeper.
In what way is it 'GitHub-centric' or 'artificially capped' though?
If I did it with `git shortlog -s` it's also going to omit the contributors from the .. I don't even know what centric way you say vim did it, and over-report commits for those who were allowed to have their names recorded properly but against commits actually authored by someone else.
It's just totally non-standard against the grain git usage.
> In what way is it 'GitHub-centric' or 'artificially capped' though?
The parent set the context of this thread by providing links to GitHub pages, that's for the "GitHub-centric", and the GitHub UI caps many of its listings to 100 items (100 pages of search results, etc.) so you only get to see the 100 first contributors, that's for the "artificially capped".
> If I did it with `git shortlog -s`
You would use an inappropriate measurement method that doesn't take into account the nature and history of the subject of your study and thus get meaningless data.
> It's just totally non-standard against the grain git usage.
There is no such thing as "standard" git usage, especially when factoring GitHub into the discussion. There are "modern" expectations, though, that the Vim project doesn't meet because it is much older than those expectations. Maybe you don't like it but it matters when discussing metrics.
FWIW, the move to Git of "the kernel" also dropped more than a decade of pre-2005/pre-git history so `git shortlog -s` won't give you the full picture there either.
I want to have both Lua and Vim9. While lua is definitely a better language for a lot of things, VimL, and Vim9 are better DSLs for directly manipulating the editor. And Vim9 takes away several of the rough edges with using VimL.
Not to mention that there are currently a lot of great plugins written in lua, and I anticipate there will be great plugins written using vim9.
That would potentially make NeoVim slower, because you could have plugins that use Lua, plugins that use VimL and others that use Vim9. That means 3 runtimes which can contribute to latency.
Shame that Bram is doubling down with vim9script. This will give vimscript a Python 3 moment, splitting an already small community into even smaller pieces.
I wish he’d have embraced Lua like Neovim. It has already been proven to work great (half my plugins are Lua these days, and it performs great), but alas, it was not to be.
Not really; the Python 3 problems were due to incompatibilities in the APIs (e.g. functions returning str previously now returning bytes) that couldn't be automatically converted, not merely due to "being incompatible".
You can safely mix VimScript and Vim9Script; you can even use both in the same file. It's not a problem. I wish people would stop using "Python 3!" on any incompatible change; the details on what is incompatible really do matter.
> I wish he’d have embraced Lua like Neovim
Vim has supported Lua since 2010, and Lua doesn't exactly have the best story on compatibility by the way.
This is all correct. To quote from the official description of vim9script:
Vim9 script and legacy Vim script can be mixed. There is no requirement to
rewrite old scripts, they keep working as before. You may want to use a few
:def functions for code that needs to be fast.
Since Vim has been Bram’s project for decades, I have some empathy for him to want to continue doing things his way and to not compromise on that. It may have taken Neovim to convince him that certain features are important, but that doesn’t mean he has to like how those are realized in Neovim. Open source is freedom, and I believe it’s okay for him to make use of his freedom to design things in his way, even if the dichotomy with Neovim is not optimal for the community. And maybe it’s not worse than (say) having both GCC and Clang.
I don't disagree with anything you've said but I would personally take this line of argument a step further. I think Bram learned from the neovim fork. Neovim bolstered the existing lua support by reducing the impedance mismatch between the lua language and the vim host. A lot of people enjoy writing lua more than vimscript but the value-add hasn't proved compelling enough for people who didn't mind vimscript. The official neovim repo still has twice as much vimscript code as it has lua code. Even if you claim vimscript is 2x as verbose that would still leave them on equal footing within the project that is putting lua forth as an equal competitor.
My impression of vim9script is that Bram had a list of goals (clearly outlined in the docs) and saw the typescript project as a model to follow. The docs themselves mention typescript as a source of inspiration for some features. The typescript project had a similar set of goals and managed to gain massive adoption both among people who had previously disliked javascript (due to the improved semantics) and people who had previously like javascript (due to the speed improvements, transpiler ergonomics, etc).
> The official neovim repo still has twice as much vimscript code as it has lua code
Much of that is "just" the runtime files (things that define language syntax, etc), which are x-compatible (broadly) between nvim and vim. Seems it would be foolhardy to just re-write all that in lua, "just because".
I agree that making a new custom scripting language wasn’t the best move, but the release notes deal with backwards compatibility concerns (and calls out Python specifically as a lesson learned).
Yeah I feel like this definitely skews the results. I’m experienced enough to nearly never use StackOverflow, and also experienced enough to want to use something robust and readily available (try to find a system that doesn’t have vim), so I stick with vim and am _incredibly_ happy with it.
Add in that StackOverflow is mostly a tool used by more junior web developers, and I think you’ll see that other demographics (like embedded, firmware, etc) would skew even more heavily in the direction of vim + no SO usage.
The participants of the StackOverflow survey are likely not people who end up on StackOverflow randomly when looking for answers, but are more likely to be people who answer questions or are pulled in from other communities that link to the survey in progress (language subreddits, etc.). The actual programming community skews way more towards learners than an SO survey shows.
You can see here that there are more people with 5+ years experience than less:
For what it's worth I prefer NeoVim and I've programmed since 2001, I don't think experience or anything has much to do with this preference.
I also think that anyone who doesn't Google stuff (and let's be honest, you'll probably end up on a Stack Exchange sub-domain when you do) for their hobby or professional programming is likely very stagnant and probably way worse and less experienced than they ought to be, since they're probably just doing the same old stuff all the time.
P.S. It's trivial to find default installations that don't have Vim, I don't get how anyone who's installed desktop or server distros at this point can not remember being surprised about the absence of Vim and having to install either it or NeoVim. I remember it being almost a regular occurrence when setting up machines.
I've been using vi/vim on a near daily basis for 34 years now and this is the only thing I put in ~/.vimrc:
set tabstop=4
set expandtab
set shiftwidth=4 " or 2 or whatever
set shiftround
syntax on
EDIT:
Just for some fun archeology, I google searched on the 3rd line, 'set shiftwidth=4 " or 2 or whatever' because I very dimly recall copying most of my standard set (minus the syntax on bit) from someone else a long long time ago. This was the only hit I found:
I tried that 'jk' thing way back, and I seem to recall it introducing some lag. Like a few milliseconds so it could process and see if you were hitting the followup key. Just enough to be annoying.
set number
setlocal cm=blowfish2
set noswapfile
set nobackup
set nowritebackup
set viminfo=
set tabstop=4
set softtabstop=0 noexpandtab
set shiftwidth=4
set noundofile
set backspace=indent,eol,start
set autoindent
set smartindent
set cindent
autocmd BufRead,BufNewFile *.vue setfiletype html
colorscheme morning
map Q <Nop>
map q <Nop>
noremap x "_x
let &t_ut=''
if has("gui_running")
:set guifont=Cascadia_Mono:h16:cANSI:qDRAFT
endif
Not the person you’re replying to but I’d guess that they don’t ever record macros and just find it to be an annoyance if they accidentally press the Q key by accident.
" My vimrc from 1994 to about 2000
set et
set ts=4
" Added this circa 2000
syntax on
" Added this ~2013
let g:solarized_termcolors=256
set background=light
colorscheme solarized
because i've always found the vi documentation a bear to navigate. i don't know what shiftwidth is even for. here's the help for it:
shiftwidth([{col}]) shiftwidth()
Returns the effective value of 'shiftwidth'. This is the
'shiftwidth' value unless it is zero, in which case it is the
'tabstop' value. This function was introduced with patch
7.3.694 in 2012, everybody should have it by now (however it
did not allow for the optional {col} argument until 8.1.542).
When there is one argument {col} this is used as column number
for which to return the 'shiftwidth' value. This matters for the
'vartabstop' feature. If the 'vartabstop' setting is enabled and
no {col} argument is given, column 1 will be assumed.
Can also be used as a |method|: >
GetColumn()->shiftwidth()
What does that even mean? And I've been using vi since 1988!!
shiftwidth has been in vi for a very long time. It's been in my exrc since I got into BSD in the 1990s, and judging by the earliest commit that's available online[0] it was added even before 1980.
tabstop is how far the cursor moves when you press tab.
shiftwidth is how far text moves when you shift it with >> or <<
Normally you'd set them both to the same value so that indenting blocks of code with >> or << shifts them by the same amount as the tabstop.
There's also another setting 'shiftround' (which I only learnt about today in another comment) which makes shifts done with << and >> round themselves to the nearest multiple of shiftwidth.
never occurred to me to use >>. probably because the three keystroke savings didn't register with me. but that's what I mean, once I learn the basics, the rest are just gravy that don't stick in my memory.
Using < and > for shifts becomes even more powerful when combined with a movement, e.g. indenting 20 lines of code at once: 20>> or indenting an entire {} block (including braces) >a{ or an entire block (not including braces) >i{
> i've always used 0i\t\t\t\t...\esc to shift.
Also consider I instead of 0i (it's not quite identical, but should serve the same purpose).
It saves way more than 'three keystrokes' redenting a block though - you must do that every line - I typically visual select then > (or <), doing the whole lot in one stroke (excluding whatever variable amount to select, v} or similar often).
I only ever end up actually manually shifting code when I'm pasting python code from somewhere and it doesn't come in with the right indentation.
If I'm working in any other language it's == (for a single line), or = after marking a region in visual mode, or magg=G'a to just re-indent the whole file.
I haven't used vim as a daily driver in ~14 years; it's weird how the muscle memory of things like magg=G'a or gqip stay in your fingertips.
I like line numbers because when I'm editing code in a remote meeting, I or someone else can refer to lines by number. The current line is not the only one that matters. I use relative line numbers because I like doing e.g. 9k or whatever. Others on a remote call often refer to other parts of the code with "9 up" or "9 down" (since "9k" and "9j" sound too alike in a noisy call).
It makes it easy to jump to other lines on your screen, e.g. maybe you want to split out half the code from a loop to another function. You can't use di{ to delete everything in the {} because you only want half of it, but if you can see that the loop contents end on line 98 you can go d98G
I gave up absolute line numbers a few years ago in exchange for `:set rnu` and while my navigation capabilities (at least to anywhere I can see) have gotten a lot faster, the ability to `>>` a handful of lines without having to count has felt a ton more productive
Nope. Back in the day that would greatly interfere with copy/paste. One way or another, it's so easy to see what line number you're on and/or jump to a specific line.
If vim doesn't have clipboard support enabled, then this is one way to copy and paste. The vim packages in the Fedora repositories are configured such that vim doesn't have clipboard support, but gvim does.
Not GP, but for me it's simply that I remember it (or rather don't need to, because it's just using general purpose mechanisms that I already remember).
But now you've said it maybe I'll remember if I need it today, and.. well I'll see.
I really wish more systems would adopt the "copyindent" pattern, where indentation is simply copied from the existing line. I've primarily developed in vim for 15 years and have similarly minimal `vimrc`s (no plugins), but some of the first configurations are always:
set autoindent
set copyindent
set preserveindent
This should be compatible with basically any language (other than some esolangs like "whitespace") and any tab/spaces scheme. There's no need to have per-file/project configuration, as long as you're okay with pressing space 4 times instead of tab in the projects that use 4-space indentation.
The ftplugin for the make filetype includes setlocal noexpandtab, which should take precedence over what's in your vimrc.
% vim Makefile
:verbose set expandtab?
noexpandtab
Last set from /usr/share/vim/vim90/ftplugin/make.vim line 15
% vim file.c
:verbose set expandtab?
noexpandtab
Last set from ~/.vim/vimrc line 56
but I think that may not work as intended for OP as they don't have "filetype on plugin".
It surely can. If I have to casually mess with a Makefile, I'll just remember to use control-v TAB as needed, or vi yank/put another line with a proper tab and edit. In the very rare case I'm doing more serious work, I'll temporarily turn it off.
You can change it per filetype. For example, I have a similarly minimal vimrc that defaults to sw=4, ts=4 and expandtab, but with the following additions:
autocmd FileType go,make,sh set noexpandtab
autocmd FileType js,json set sw=2 ts=2
Edit: I think you might also need the following to make it trigger the FileType event when you open a file in the first place:
The most important ones lately seem to be the LSP integrations (basically IDE features like autocompletion, go-to-definition etc) and auto-completion managers. But honestly it's been breaking all the time over the last year or so that I code more often in VSCode and maybe it's about time I stop trying to make an ever-improving IDE out of Neovim :(
Neovim project's direction seems to be aligned with making it easier to have IDE-like experience with LSP integration but it's been painful in Neovim. In Vim, it's typically even worse and even harder to set it up.
Overall, I've been using Vim for about 8 years and went from a really simple set-up of "this is just a text editor" down the IDE rabbit hole. I also went for Vim -> Neovim -> Vim -> Neovim and eventual split of the two configs in the end and. I'm thinking about making it much simpler again :D
It depends what kind of person you are, how much energy you want to invest, how much patience you have for stuff that isn't the code you're writing, how much you enjoy editing itself, etc.
I have a quite extensive setup (https://github.com/Julian/dotfiles/tree/main/.config/nvim) which I built up over 10+ years, indeed sometimes including sitting there for an hour or two and just investigating plugins or writing some function to make editing easier. I enjoy it, and it means I can do lots of things in my setup that involved time investment.
Others obviously just want to get on with their work.
To me though part of the reason I use vim/neovim is because anytime something annoys me about editing I can automate it, or find a plugin which has done so already.
This is what I love about vim. Ironically, I think that the barrier to writing a plugin that solves your problems is lower in vim than an IDE. Pair that with portability, and you have a cozy environment you can feel safe investing hours into.
No idea if I'm typical or an outlier, but I have a couple of syntax highlighting plugins, NLKNguyen/papercolor-theme, a vim rc file with my favorite keybindings (e.g. faster navigation among splits), and a python file with some helpers for opening terminals in vim and... that's it.
Every once in awhile I think I might do a fancier setup but then I lose interest. Ditto for checking out neovim. I'm sure I'd get some gains, but I guess I've sort of settled into a decent sweet spot that I haven't left for almost a decade, haha (been using vim for ~25 years total).
For me, I'll say "never ending-ly" deep. I've been hacking on Vim for the last 20ish years. First plain old Vim, and in the last 3 years, NeoVim. Even this morning I started by switching out VSnips (snippet manager) for Luasnip. I am always looking at things that could make my dev life more streamlined. I don't really care so much about having a bunch of bling plugins (although I do have a nice status bar, and a file tree). I'm more looking more at the things that I do on a day to day basis. Are there existing plugins that fit those patterns? If there are, I try them out. Sometimes I have to write the functionality myself. (Want to console log the variable under my cursor, with a label? Done.)
Since this editor (and Emacs) are SO extensible, it's hard to find two long-time users with similar configs.
I think this really depends on whether you have a good way to track your dotfiles or not, as configuration is accretive with time: you make changes as you find you need to scratch an itch. Config changes are lost without some way to sync across systems.
Previously to managing my dotfiles, my .vimrc was usually 4-5 lines, written by hand on each machine I sat at. This was my first 20+ years of vi/vim.
Once I started managing dotfiles across systems (~3 years ago), my .vimrc has grown to be ~700 lines. My .bashrc has also grown to almost as much for reference.
Like most, the work in customizing .vimrc is in configuring plugins and making sure they don't conflict with each other, but also, I've taken care so that I can use the same configs across Linux and Windows, allowing me to use the same tools, plugins and configurations regardless of the underlying OS. Neovim is my tool of choice on both OSes but my configs fallback well to vim or other vi implementations rather gracefully (via bash/pwsh alias trickery) for when needed.
Regarding plugins that I would never operate without (of the many installed):
- nerdtree (and friends like nerdtree-git-plugin, vim-nerdtree-syntax, vim-devicons) for decent file nav integration
- vim-fugitive (Git integrated into vim, makes interactive commit creation and navigation easy from within vim)
- Coc for language server support that works on both sides of the fork and vscode like plugins.
Also, not a plugin, but worth configuring in your environment: neovim-remote. I use this to make "vi <file>" open the file in a new tab, rather than start a nested editor, from within a terminal window within neovim (again with more shell alias trickery dependent upon $NVIM_LISTEN_ADDRESS being set or not). Using it for $EDITOR and $VISUAL when NVIM_LISTEN_ADDRESS is set is also really useful when invoked indirectly by tools being run in a windowed terminal e.g. "git commit" or "kubectl edit".
If you aren't tracking dotfiles, I really suggest you start. It's really cool to be able to sit at a new system, sync some files and get your editor / development environment installed/booted with all the bells and whistles you like installed ready to go. You will find that there is no end to this rabbit hole in the end. I think that's a good thing :)
Vim only has that reputation of needing a lot of config because too many newbies want to skip the learning phase and just jump in between two JIRA tickets. Of course you will need a lot of plugins and pre-baked stuff and hand-holding in that case!
The more sensible path is to learn Vim properly, and configure it as you go. It means that there's never a "take the week-end to configure Vim for React" moment: it's one line here, two lines there and it never really stops because you work with new languages and libs, etc.
As far as plugins. I can use Vim just fine without plugins or without my config but half of the plugins I use are written by me and tailored around my own needs so I guess those are the ones I need the most for my daily use.
I put some time into learning vanilla vim to a fairly basic level, about 20 years ago. It’s been sufficient ever since. Occasionally I look up rarely used commands, but as far as I’m concerned my configuring days are over.
It’s definitely a deep rabbit hole. There’s a lot to figure out - even as an old vim user moving to a more modern neovim setup about a year ago.
One of the issues I found was that every plugin seemed to reference other plugins and you need to figure out how to make them play nicely together yourself. Most of the best info is just buried in GitHub issues and neovim was such a moving target that everything needed more digging into to get working correctly.
For me now essentials include; Telescope, Trouble, Cmp and a good LSP setup.
Specific plugins I use all the time: bufexplorer (though I've mostly rewritten it), ctrlp, colorizer, syntastic, vim-commentary, vim-projectroot, vim-surround, zeavim (Zeal integration, similar to Dash on macos).
Out of everything, if I want to use (neo)vim as a serious code editing environment, it has got to be LSP support. To that end, I use coc.vim although of course there are many other LSP plugins.
I've gone down that rabbit hole quite a few times and each time for a much longer period than I am willing to admit. I use neovim for hobby development and as a general text editor.
The plugin that I find myself using all the time is vim-surround with a couple of minor language-specific tweaks.
ALE and CTRLP are the most non-vimmish ones I guess. Most of my remaining plugins are extensions to Vim, like highlighting unique characters when pressing f, or highlighting my latest yank, or more text objects, or autopairs, surround, etc.
.vimrc currently sitting at about 275 lines (including whitespace and comments). A big chunk of that came with the terminal integration, as I'm using `term_sendkeys` heavily.
Is there something equivalent for LunarVim[0] or NvChad[1], in Vim ecosystem? I want to try something different. I learn a lot hacking around these opinionated setups.
I loved vi for decades, but I don't miss it. Neovim is my current go-to but even this feels stodgy these days. Helix Editor is probably my future -- it manages to have just the right features, but with saner defaults and syntax -- but it will take a while for me to work up the nerve to let go of the investment in muscle memory.
I don't think going all in on treesitter is very practical, considering basic python indentation has not been functional for over a year. I think Helix is a little bit too much of niche layered on niche, and Kakoune is much better all around in my experience.
that sounds hard but I... don't often code in python?
I can see bolting a fallback regex mode for the few languages that have features which ts cannot (yet) accommodate.
And 'niche layered on niche' is -- well, it leaves me wondering how much you've actually used hx. The experience is nominal, the installation is sane, and it was way faster to get to 'genuinely pleasant' than nvim ever was.
As a plus, nix home-manager also handles helix config, which, as a nixos user, puts it over the top for me.
(home-manager also does nvim, but this is mostly mooted by my need for an elaborate (and turing-complete) Packer configuration, which has me using a separate git repo for nvim specifically)
I don't often code in python either, but it's a considerable red flag that one of the largest languages in the world has been completely broken for this long. It makes me not want to invest time building muscle memory for the editor. Sometimes I need to code in python, and when I do, I don't want a lot of inconsistencies and jank.
That's what I mean by niche layered on niche- the editor itself is a niche project that leverages another niche project (tree-sitter) to do indentation, and when contributions on either aren't up to par it kind of falls apart.
I have used the editor a decent amount and it's quite nice when it works. I don't even mind the lack of plugin extensibility because there's not really anything I needed that wasn't built in.
I'd like to point out that the editor is barely a year old and I'm working on it entirely during my free time. It takes time to sort out all the issues and provide excellent support for all languages. I primarily write Rust and Go so those are guaranteed to work well.
It's hard to do tree-sitter query based indentation with space based languages, because the indent has semantic meaning and the AST node is invalid until indentation is typed out. We do have a potential solution (https://github.com/helix-editor/helix/issues/763#issuecommen...), it just needs someone to go and implement it.
I don't consider tree-sitter niche though. Outside of VSCode it's widely adopted, but yes it's probably too soon to only rely on tree-sitter with no fallback. Of course we do implement fallback behaviours too: we try to use tree-sitter first, then provide a simpler fallback for cases where there's no grammar available (or like in this case, it's not a great fit).
I am currently looking forward Helix too. I like the Kakoune philosophy (Object - Action rather than the contrary) better and I like the out of the box experience they are aiming at.
I never really enjoyed having to configure vim. What I like about vim is the idea of modal editing which and the fact it runs and interacts in/with the shell. Still waiting a bit more before making the jump.
My work machine is Windows and I pretty much spend most of my time on IDEs like JetBrains IDEA or VSCode (too many capabilities to search equivalents for via Vim on Cygwin). Both have plugins for Vim keybindings. So for me, Vim is always present through the spirit of its keybindings which have become second nature.
I stuck with Vim for a long time. I had friends that made the jump and honestly, around version 0.4.3, it still didn't seem to offer anything I cared about. So I stuck with my decade old .vimrc. I had started to get into CoC stuff, and NeoVim was just starting to release their native LSP integration. On a whim, I decided to give it a shot. I ended up sticking with it. Now there'd have to be a heck of a good reason for me to go back. I never enjoyed VimL. Any of the personal plugins I've written, I've had to struggle through writing. While Lua isn't the most amazing language either, I do like it far more. I feel like NeoVim's ecosystem is pushing the boundaries far more than Vim but, isn't that kinda what Vim wanted? They want to remain the conservative slow-moving text-editor. There's nothing wrong with that at all!
Neovim occasionally has really basic functionality regressions compared to vim: I switched back to preferring vim after realizing that neovim silently deletes all ACLs on a file (https://github.com/neovim/neovim/issues/1200).
However, I use Emacs and VS Code for more involved editing, and mostly use vim as a light remote editor via SSH, so my priorities may be very different.
So lots of neovim growth, but still small in absolute numbers. Then again, vim-tiny is installed by default. Normal vim is a better indicator. And it won't grow as much, because Debian's userbase grows slowly.
Personally I'm happy with the default Vim config (I'll enable features if I need them, such as line numbers) and prefer the minimalism.
I tried neovim but there were more bells and whistles by default, and I didn't want to waste time configuring (and I work on a bunch of machines when wearing my sysadnin hat). For plugins, I only use a debugger.
I switched to NeoVim and then back to Vim a few years ago. I ran into some bug that prevented my setup from working correctly that forced me back. Vim has been working fine for me and I haven’t found the motivation or a reason to try and switch again.
It was only in the last year or so that neovim really hit its stride. Features like treesitter provide the basis for some really interesting functionally.
I use vim for a living. I need it to work. Always. Neovim in my experience hasn't been as stable, not by a longshot. Neovim adds things I don't care about (lua, lsp, treesitter) while taking away things that are essential to me (gvim, rock solid stability).
I see the neovim community holding up lua as a holy grail, rewriting entire vimrc configs just for the sake of it (even though a vimscript vimrc is much easier to read than a lua one) and rewriting rock solid existing vim plugins in lua, resulting often in a less stable and less feature complete plugin. But hey, it's now written in lua so it MUST be better!
I prefer VimScript over Lua. VimScript is really not that bad of a language and I think its deficiencies have been greatly exaggerated, and Vim9Script fixed most of the oddities that were in there (e.g. '1' == 1 and such, JS/PHP-style).
Lua, on the other hand, won't give me an error if I mistype a variable name, and the ecosystem doesn't really have good static analysis tools to catch these kind of silly errors. There's some other things I don't like either, like how "arrays" are really just hashmaps, as well as some other things. The whole versioning story wrt. compatibility is also annoying (it's basically a Python 2/3 story with every single Lua version).
It's not Lua is horrible, but the fawning over it from some Neovim people is something I always found curious, like it's a fantastic brilliant language. Meh, I found it quite average overall, at best. And if I look at some Lua vimrcs or plugins then it's all a lot more verbose and awkward than VimScript.
Not that VimScript is perfect by any means, but overall I find it's quite a decent DSL for an editor.
Fair, though neovim uses LuaJIT which is maintaining Lua 5.1 compatibility indefinitely; with their own set of extensions[1].
Through the use of metatables you can improve the undeclared global situation[2], through I admit it's kludgy.
We use luacheck for static analysis, but I'll admit it's far from perfect. The language doesn't lend itself well to static analysis.
I think what lua mostly has is a really good embedding story. It's a tiny C library with broad compatibility and a permissive license; and with LuaJIT it's also very fast (though less portable). This means it's used everywhere and a lot of people are at least passingly familiar with it. Vimscript on the other hand is fairly alien.
I feel the same way. Legacy vimscript certainly had some warts but vim9script has been much nicer IME than lua. Elsewhere I've likened vim9script to typescript 1.0. It has just enough types to be useful but not enough to let you go down a rabbit hole. That's sort of the sweet spot when scripting another application.
I might be wrong, but I think math favors different starting indices based on the subject matter. I've seen Analysis textbooks favor 0 as the starting index. I don't think there's a clear argument for cultural transference from math.
I'm opposed to starting index from 1 because I think departure from very mainstream programming tradition should have a strong reason beyond preference, even if the de facto tradition appears equally capricious.
Debatable. It makes sense to say "the first element", regardless of mathematical connotations. We've had this kind of expression in almost every language across the world long before we invented multiplication.
Saying the "the zeroth element" is just... weird and slightly nonsensical.
I agree that is very weird at first. But after building a toy project including about 5,000 lines of Lua, I can say I got used to it fairly quickly. Most of the time, I was accessing arrays via iterators anyway, so I had to deal with indices very rarely.
Aesthetically, it is repulsive, but when actually writing code in Lua, it was not much of a problem. I felt much stronger about "do"/"then" and "end" versus curly braces for delimiting blocks.
Do you have any details on that? I tried looking at default packages and containers for each version but those are probably too slimmed down. I assume you mean installed by default when you pick a "desktop install".
Really surprised to see /Debian/ of all things pick Neovim, especially years ago when it was even newer, as a default over Vim and would love to see the discussion around it. It would have been ~v0.2 for Stretch and ~0.3 for Buster, and only a year old during Jesse.
I've tried Neovim a few times but kept getting discouraged by things like pane navigation being different and the replacement for netrw seemingly not being able to be configured to have similar keybindings. Last time it was something to do with :term or :vertterm.
I'm someone else, but I did the same thing 5 years ago.
For me, the most productive environment for writing and reading code is an editor with rich language support. Text editing ergonomics and startup time are completely trivial aspects of the user experience compared to proper language support. Although vim is improving, its plugin system, configuration mechanisms and plugin ecosystem is an afterthought and requires way more fidgeting, setup and hacking to just barely be useful.
When I made the switch, Bram was still vocal about how he regarded the sort of language support plugins I wanted as undesirable or irrelevant, and made no effort to accommodate things like LSP. This has changed, but at this point, it's too late. VS Code supports all the languages I need through a set of plugins it wouldn't even be possible to implement for vim, with no fidgeting required. Although I still love vim's text editing capabilities, they're not nearly enough to tip the scales.
I still use vim for quick text file stuff, and even write commit messages in vim in VS Code's terminal. For actual development though, it'll never be as powerful and low maintenance as VS Code.
I also tried VSCode and it is sooo great. But what got me back into Vim was that VSCode sucks as an editor itself. It outsourced formatting to mostly opinionated linters^ and has only primitive two-regexp based indenting rules. Nothing even remotely comparable to vim/indent. Most linters only operate on a whole file, so there is no `5=`. This drove me mad eventually and I went back to Vim, despite the costs.
I tried neovim-based vscode integration and didn’t find it comfortable enough.
^ I don’t really care of one or another way of formatting, but it messes with my code way too much, cause I’m using hyperscript not jsx. The way these linters format highly hierarchical calls is just stupidly bad.
I kinda miss Bill Joy VI and Keith Bostic NVI. In saying that, I know nvi owes Elvis more than a little.
Vim is sort-of the defacto reality in my life now, but if two or three things around tab expansion and tab-to-space got fixed, I'd stick to nvi compiled and installed from pkg/ports/homebrew over anything else.
Vim 8 changed a lot of defaults - it enabled things like search as you type, scrolling as the cursor moves down the page rather than at the last line, etc.
A vimrc could revert this to standard behaviour, but that means having to have a vimrc file.
But most Vim addons seem to be written in Vimscript, and porting them to another language (which?) is a lot of work for little practical gain (for many/most addons).
Okay, I did a quick grep through the documentation of my distros current vim installation and came up with support for Lua, MzScheme, Perl, Python, Ruby and tcl.
So yeah, there are lots of interfaces to chose from.
Vim script has a long history and initially it emerged from vi commands. It is intended to talk to Vim internals, so any other language will always look and feel alien in this regard. I hope Vim script will continue evolving, albeit breaking backward compatibility.
What do you want to do? My best advice would be to search up some dot files from people you may follow on GitHub. There are all kinds of configs, but typically just fork someone’s you like then make minor tweaks. Here’s mine, I also linked the three people I copied from in my read me:
Is that a thing anyone does? Follow people on github? I'm vaguely aware that they tried making github social media but I never heard of anyone actually using it like that.
I don’t really follow people for the social media. If there are devs I like I get to easily see what projects they follow, fork, or contribute to. It a good way to see what’s out there IMO, project wise. I found many awesome libs and CLTs this way.
You can either use lunarvim or nvchad to get started quickly. It's easier to override default bindings, plugin config etc. in nvchad. Or you can use their configuration as reference and pick and choose what you need.
Stability. I was a long-term vim user before moving to neovim, and during my time using vim, I could count backwards-incompatible changes on one hand. Plugins rarely broke because of the editor as well. While neovim is a fast moving target (they haven't released a 1.0 version yet), sometimes the editor breaks the plugin API so you'd need to wait to upgrade until your plugins are ready for it.
