Practicalli Astro: rainbow-delimiters.nvim plugin issue
During a plugin update today, SPC p a , the rainbow-delimiters.nvim plugin caused an error
Failed (1)
â rainbow-delimiters.nvim 1.97ms îȘ User AstroFile
fatal: not a git repository: ../../../.git/modules/.luals/addons/busted
fatal: could not reset submodule index
Pressing x on the plugin name marks it for deletion.
Then quit Neovim Space q .
When Neovim is started again the the rainbow-delimiters.nvim plugin will be updated cleanly.
Assumption: a rebase or other change in the plugin's git history caused the update process to trip up, as the lazy package manager couldnt pull newer changes on top of the existing git history.I would be interested to see a retrospective on how you feel about your current setup with neovim compared to emacs after all this time. I was surprised you switched after all the love you poured into it lol. I'm still using a lot of your ideas even years later lol.
Yes its a very good idea. I will write a blog post about it
Some initial thoughts: I would still use Emacs for some activities (software archaeology and really heavy refactor of large code bases) and it Emacs is more feature rich than Neovim. I haven't needed as many features in the last couple of years and its been nice to focus on editing speed and simpler interactions with the editor. Also just to try something new. I keep an interest in Emacs, especially Clojure Mode for treesitter. Once treesitter is widely adopted by package maintainers it should give Emacs a significant boost in performance. Emacs has also merged Pure GTK libraries, so the UI should be more responsive (especially on Linux +Wayland and maybe Windows + WSL) There is much more detail I can go into for a retrospective -https://github.com/practicalli/practicalli.github.io/issues/7.
I felt like tree-sitter basically lost the momentum race to lsp, is that unfair? I'm missing something?
thanks for this write up though!
I think of Treesitter and LSP as different things. LSP defines a protocol for common tooling while tree-sitter is an incremental parsing tool and library, supporting multiple languages However, LSP could use Treesitter to greatly simplify its implementation, especially where treesitter is an integral part of the editor. Treesitter could also be used by features outside of the LSP protocol and many more packages could benefit. Treesitter has been in Neovim around 4 years now, so many of the editor features and plugins make use of it. Emacs 30 seems to have a stable Treesitter implementation, so hopefully Emacs package maintainers are noe able take advantage (like with clojure-ts-mode)
thanks, in addition to what you said here, i found this picture fairly helpful in understanding some of differences...