Our great sponsors
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
NvChad
Blazing fast Neovim config providing solid defaults and a beautiful UI, enhancing your neovim experience.
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
-
-
-
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
> 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".
https://github.com/neovim/neovim/search?l=vim-script&p=1
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
Having gone from a stock vim to a highly modified vim and back again, here are some plugins that I find really boost my productivity:
- neoterm, for opening a REPL in a split buffer and quickly sending chunks of lines to the REPL (https://github.com/kassio/neoterm)
- fzf for faster buffer and file navigation (https://github.com/junegunn/fzf.vim)
- vim fugitive for good git integration (https://github.com/tpope/vim-fugitive)
- some other tpope plugins (surround, unimpared, commentary, vinegar)
Having gone from a stock vim to a highly modified vim and back again, here are some plugins that I find really boost my productivity:
- neoterm, for opening a REPL in a split buffer and quickly sending chunks of lines to the REPL (https://github.com/kassio/neoterm)
- fzf for faster buffer and file navigation (https://github.com/junegunn/fzf.vim)
- vim fugitive for good git integration (https://github.com/tpope/vim-fugitive)
- some other tpope plugins (surround, unimpared, commentary, vinegar)
Having gone from a stock vim to a highly modified vim and back again, here are some plugins that I find really boost my productivity:
- neoterm, for opening a REPL in a split buffer and quickly sending chunks of lines to the REPL (https://github.com/kassio/neoterm)
- fzf for faster buffer and file navigation (https://github.com/junegunn/fzf.vim)
- vim fugitive for good git integration (https://github.com/tpope/vim-fugitive)
- some other tpope plugins (surround, unimpared, commentary, vinegar)
Is there something equivalent for LunarVim[0] or NvChad[1], in Vim ecosystem? I want to try something different!
[0]: https://lunarvim.org/
[1]: https://nvchad.github.io/
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:
https://github.com/azemetre/dotfiles
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.
I've spent so much time on configuring my (Neo)vim over the years I wouldn't even be able to estimate it (here it is if you're curious: https://github.com/kirillbobyrev/dotfiles/tree/main/.config/...).
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
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.
[0] https://github.com/weiss/original-bsd/commit/3effe8f62d3c7b5...
If you have any issue with them (well… beyond "I don't like it"), feel free to open an issue here: https://github.com/vim/colorschemes/issues
> it kind of falls apart
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).
That's not necessarily true.
Core maintainer of the Neovim Tjdevries is working on a compatibility layer that would allow vim9 to not only run in Neovim, but likely faster.
Source: https://github.com/tjdevries/vim9jit
Doom Emacs is a better alternative IMO (having used both extensively).
https://github.com/doomemacs/doomemacs