-
> 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
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
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)
-
NvChad
Blazing fast Neovim framework providing solid defaults and a beautiful UI, enhancing your neovim experience.
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
