161–170 of 272 posts
Earlier quoted context omitted.
Yep, "neovim taking the IDE route" is a bad take.
What it means in this context? Creation of GUI? Vim is basically IDE at this point, if you configure it well and install plugins.
So the idea is Neovim by itself isn't an IDE. But it does enable you to build an IDE using configuration and plugins, or even embedding it in a GUI.
Earlier quoted context omitted.
Curious as to why you set ts but not sw?
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…
[0] https://github.com/weiss/original-bsd/commit/3effe8f62d3c7b5...
Earlier quoted context omitted.
Vim has been around long enough that I'd argue it's just as much owned by the community at this point.
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. [0] https://github.com/vim/vim
Earlier quoted context omitted.
This has entered the popular lore but I think it is easily proved false. The thread in question: https://groups.google.com/g/vim_dev/c/-4pqDJfHCsM/m/LSFNhqs2... 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 proce…
> The patch authors never replied. They may develop under aliases but I've never seen either of their handles in the neovim commit history. So, who forked neovim and what does this timers patch have to do with forking if the patch authors weren't the ones forking neovim.
https://groups.google.com/g/vim_dev/c/65jjGqS1_VQ/m/fFiFrrIB...
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:
https://news.ycombinator.com/item?id=7279358
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.
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…
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.
Earlier quoted context omitted.
Curious as to why you set ts but not sw?
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…
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 There's also another setting 'shiftround' (which I only learnt about today in another comment) which makes shifts done with > round themselves to the nearest multiple of shiftwidth.
Earlier quoted context omitted.
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…
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 There's also another setting 'shiftround' (which I only learnt about today in another comment) which makes shifts done with > 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.
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…
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…
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.
I'm curious: - How deep a rabbit hole do most people go down when setting up their vim / neovim environment? Apart from setting up a preferred color and language specific tab spacing and highlighting, I don't need more, but I've seen some pretty fancy setups. Out of the different plugins, which would you never operate without?
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 " 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 :)
I'm curious: - How deep a rabbit hole do most people go down when setting up their vim / neovim environment? Apart from setting up a preferred color and language specific tab spacing and highlighting, I don't need more, but I've seen some pretty fancy setups. Out of the different plugins, which would you never operate without?