Hi! I’m the author of packer. I’m glad you find the configs more readable, and fully acknowledge that there’s a lot of polish to go before packer is as smooth in all regards as vim-plug (in particular, a fix to running plugin configs before they’re installed is awaiting merge, and a fix for needing to manually run PackerCompile is in the works), but I’m surprised that you found PackerCompile to ever be slow - in all my testing, it takes a negligible amount of time to run.
If you have a reproducible example for when it’s slow, do you mind filing an issue? I’d love to dig into why that happened for you. Thanks!
Hi! Thank you very much for writing packer. That section of my article was written quite early in my exploration, and I ought to have revisited it as my understanding improved.
In case my article gave anyone an unnecessarily negative impression, I want to re-emphasise that I use Packer and there are many things about it that I like. It’s relatively new code, but I see it moving steadily in the right direction, so I’m not bothered by a few bugs I encounter on the way. It’s been a while now since I wrote that it’s “tolerable”, and my opinion of it has only improved since then.
I do still have the problem I mentioned, but I now realise it isn’t that PackerCompile itself is being slow, but that sometimes after I save plugins.lua, a bunch of other stuff happens after the PackerCompile, and the save completes only after several seconds. For example, I see gitsigns.nvim running git --no-pager --version dozens or hundreds of times, and the lua-language-server being restarted a few times. I don’t really have a handle on the behaviour yet (it doesn’t happen every time, but nothing like this happens for anything but plugins.lua, with the autocmd to run PackerCompile). I’ll definitely file an issue once I have some indication of how to reproduce this.
It is exciting to see neovim gaining such novel and useful features like first
class Lua scriptability (you can even access libuv event loop from the Lua!),
LSP client and online syntax parsing (treesitter).
Personally, while I use neovim since 0.1.x versions I’m not eager to take the
advantage of those 0.5.0 new features. I want to wait some time before dust
settles. There are lots of new Lua plugins pop up for neovim (some brand new,
some rewrites of vimscript based plugins into Lua) and I want to wait and see
which will become more robust and mature.
Regarding the LSP I still use ALE which, I think, has some of the best UX:
Support for non-LSP linters and fixes (autoformatters mostly). This means I
can use the same UI to see diagnostics from both LSP and non-LSP sources. This
is really important for me.
A huge collection of integrations with LSP servers and linters. Sometime I
discover a linter/LSP for a new file type I’m editing by just invoking
:ALEInfo and seeing a list of suggested integrations.
I think all of this is possible with neovim’s new LSP + some configuration on
top (like using null-ls for non-LSP linters/formatters). But… it all requires
some friction for configuring it right while ALE gives you all of that out of
the box.
Thanks for the recommendation. I tried neovim but gave up after half an hour of failing to configure its LSP support and after becoming annoyed that they change the undo file format but don’t change the extension so you can’t edit the same file with vim and neovim. I tried ALE and it took about 10 minutes to get it working nicely (well, spread over two days, poking it a bit while I waited for things to build). It does exactly what I want and it’s added a total of under 10 lines to my vimrc to have nice clang-format and clangd integration.
I ended up moving off Vis because of the lack of Language Server support. For Rust development, that’s the difference between a ~5s feedback cycle and a ~200ms feedback cycle.
Likewise, though it’s syntax highlighting system is simple, it is pretty bad for Ruby, where every variable ends up highlighted like a method name (since it’s impossible to tell the difference). Turn that off, and method signatures aren’t highlighted anymore.
What are some crustacean experiences with Treesitter?
I tried it out, despite the warnings about instability, for the refactor plugin. Got this Unity codebase to deal with, and nothing else really provided C# refactoring.
The refactoring wasn’t project-wide, which caused some woes, though I could repeat the operations a few fimes in separate files and be happy-ish. The dealbreaker is that Neovim would quite often deny insert mode, as if the buffer setting changed BTS somewhere. Restart, my favorite!
I don’t use treesitter ATM, maybe later.
LSP is also a mixed bag. Very useful and works nice on my heirloom-grade laptop, even for Unity, but on my desktop it buffers up syntax errors for nearly every keypress and flushes them out so slowly I can jump to Unity and run the unit tests by the time LSP’s done complaining. Sometimes an error is left lingering.
This is with the same config on both machines, and OS load is always less than you’d imagine, so it’s just weird. Even mono should be the same version.
No regrets; C# needs this stuff so bad it’s worth the trade-off.
For typescript it was a game changer. Syntax highlighting in vim never looked quite right, especially in a side-by-side comparison with VSCode.
I also find the neovim ecosystem to be rich and full of new plugins because of things like tree-sitter support. There’s an entire section dedicated to treesitter enabled colorschemes on neovimcraft: http://neovimcraft.com/?search=tag:treesitter-colorschemes
Treesitter might be laggy enough or something to trigger the problem more often. Testing that fix now, and maybe I can give Treesitter another shot soon!
Could you expand on this? I would expect C# to be the language with best refactoring tools, given that both JetBrains (Resharper & Rider) and Microsoft (Roslyn) have been working on them for more than 10 years at this point.
Roslyn is MIT licensed, omnisharp makes it speak LSP. For refactors specifically, I’d be surprised if there isn’t non-editor tooling to apply Rosly analyzers as project-wide refactors.
Sure. However actually using omnisharp is another matter. Its definitely not on par with the experience inside of visual studio itself. For example vscode which uses omnisharp provides a pretty demonstrably second class experience compared with rider and visual studio proper. And even then that experience is better than what you get from lsp c# in neovim.
An example of this breakdown is that msbuild integration with visual studio is on a whole other level compared to what omnisharp can handle
I did find this one refactoring plugin vim-refactor that pulled in a bunch of library-like stuff, less surprisingly conflicted with some of my maps, and didn’t do c# properly in the end.
That’s why Treesitter seemed so appealing. I’m sure it’s not such a turd as my experience was, but I also have work to do beside debugging 0d plugins ;)
I do really look forward to trying it out again, but I’m happy with my LSP setup (despite the error stuff!) and able to be productive now.
I still don’t understand something I believe. Roslyn is a very mature tool to do analysis and transformation of C# code. Using tree sitter for refactors (which knows only syntax) is like parsing html with regexes, only one level up: using syntax analysis for semantic transformations.
If, despite all this, “refactoring C# in vim” is still an unsolved problem, then there’s an opportunity for a fairly easy, fairly popular OSS project here. All the hard work of actually doing refactors has been done by Microsoft. What’s left is the last mile of presenting what Roslyn can do in an editor.
Maybe my “repeat in multiple files” is because of syntax being the wrong layer? I’m really not 100% sure!
It was palatable, and got the job done, and the dealbreaker was something else.
I do have OmniSharp running, but I haven’t seen anything related to proper refactoring in Neovim with it. I could look again and verify I have the latest version, though I did take a quick look before my Treesitter journey.
It would be beyond awesome if more native refactoring existed, but I do believe it’s more of an opportunity than an existing feature.
Current OmniSharp-vim maintainer here. All of the OmniSharp-roslyn code actions are available in OmniSharp-vim. OmniSharp-vim doesn’t actually use LSP, as both OmniSharp-vim and OmniSharp-roslyn are older than the protocol.
However the OmniSharp-roslyn server does have an LSP “mode” and so is usable without OmniSharp-vim using vim LSP plugins or neovim native LSP. I would expect all code actions to be available via LSP too but I don’t know.
I’m curious to know what kind of server-based refactorings we’re talking about exactly.
My use case is/was simple: given a code base, rename methods so they’re renamed everywhere. The start of the rename can be a method definition or a usage, and everything will be figured out. Not sure if that’s possible, even, just a wishlist thing ;)
I haven’t needed to touch constructor (or other method) argument refactoring, and I’m sure the Treesitter refactor plugin has nothing for this, but could be useful.
TIL! Thanks! Now I got a config with treesitter that disables the refactoring prompt in c# in favor of an autocmd map for omnisharp :)
Edit: yet to see what needs to be reloaded to get rid if the “does not conrain a definition (though it sure does lol!)” error, but still this is good news :)
Edit2: jumping the gun here, :LspRestart seems to be good enough.
Right, if you’re using LSP and OmniSharp-vim together, you’ll have to find ways of keeping the servers synchronised, because you’re running multiple instances.
Yeah, it’s a bit messy but most often only when autocompleting. I approach my neovim pretty much by fixing things as they start to annoy me too much or cause a productivity hit.
Maybe I’ll get that thing sorted some day, but I’m fine for now :)
I’ve been on a similar journey going from VSCode to neovim. I’m using a very different set of plugins, but not too different from the author. I’ve had a great experience with coc, particularly coc-eslint and coc-tsserver for my LSP needs!
It would be great if there was one place to find examples of these frankinvim configs. With all these features neovim could be a drop-in replacement for someone coming from VSCode or sublime.
A cleaner separation between the processing engine and the UI is one of the more important neovim-over-vim improvements to me. While I suspect the audience here tend to use the terminal emulator path, are there any other daily-driver/heavy users that use any of the alternative UIs?
I use Firenvim on a daily basis, does that count? :^)
I think most windows users prefer using a Neovim GUI (probably Neovim-Qt since it’s bundled with neovim on that platform) because the windows terminal is not very nice to use. I’ve tried most of the linux GUIs and even though some are really nice (Goneovim is my favorite) I still prefer using a terminal. I find that GUIs don’t offer much over just using a terminal (yet?).
I remember you built your own Neovim GUI that integrates with Arcan, does it do anything special?
I remember you built your own Neovim GUI that integrates with Arcan, does it do anything special?
Indeed. I worked through that list for more interpretations of the documentation (~2.5 years ago) and got the feeling that most started and either gave up, or got to the PoC stage and for some reason stopped before getting to the more complex bits. Msgpack by trial-and-error is quite painful, especially in C.
There’s only one real thing arcan-nvim does “special” right now and that is the integration to “universal load/save” (which is a riff on how drag-drop, cut-paste works). The point of that is I can dynamically send it descriptors and get copies of the current buffer. This lets Pipeworld use it as a cell in a pipeline, so whenever a dependent part of the pipeline or other expressions use it, the active vim buffer will be snapshotted and used. Then it can be used as a building block for making REPLs out of anything. The one I’m testing against for the moment is (nvim-arcan| latex | apdf | nvim-arcan), so a native arcan-tui application, a “isatty()” legacy terminal program, a native arcan graphical program and back to nvim.
What I started it for was testing the arcan-tui (ncurses replacement) API and the server-side text rendering. The real ‘meat’ is the multigrid / popup integration that still isn’t finished. The point of that would be that completion popups works as discrete windows in the WM space, and that, for instance, :vs would actually give a logically new window that the window manager would understand and treat as vertical-split and integrate with the current policy.
Hi! I’m the author of
packer. I’m glad you find the configs more readable, and fully acknowledge that there’s a lot of polish to go beforepackeris as smooth in all regards asvim-plug(in particular, a fix to running plugin configs before they’re installed is awaiting merge, and a fix for needing to manually runPackerCompileis in the works), but I’m surprised that you foundPackerCompileto ever be slow - in all my testing, it takes a negligible amount of time to run.If you have a reproducible example for when it’s slow, do you mind filing an issue? I’d love to dig into why that happened for you. Thanks!
Hi! Thank you very much for writing packer. That section of my article was written quite early in my exploration, and I ought to have revisited it as my understanding improved.
In case my article gave anyone an unnecessarily negative impression, I want to re-emphasise that I use Packer and there are many things about it that I like. It’s relatively new code, but I see it moving steadily in the right direction, so I’m not bothered by a few bugs I encounter on the way. It’s been a while now since I wrote that it’s “tolerable”, and my opinion of it has only improved since then.
I do still have the problem I mentioned, but I now realise it isn’t that PackerCompile itself is being slow, but that sometimes after I save plugins.lua, a bunch of other stuff happens after the PackerCompile, and the save completes only after several seconds. For example, I see gitsigns.nvim running
git --no-pager --versiondozens or hundreds of times, and the lua-language-server being restarted a few times. I don’t really have a handle on the behaviour yet (it doesn’t happen every time, but nothing like this happens for anything but plugins.lua, with the autocmd to run PackerCompile). I’ll definitely file an issue once I have some indication of how to reproduce this.It is exciting to see neovim gaining such novel and useful features like first class Lua scriptability (you can even access libuv event loop from the Lua!), LSP client and online syntax parsing (treesitter).
Personally, while I use neovim since 0.1.x versions I’m not eager to take the advantage of those 0.5.0 new features. I want to wait some time before dust settles. There are lots of new Lua plugins pop up for neovim (some brand new, some rewrites of vimscript based plugins into Lua) and I want to wait and see which will become more robust and mature.
Regarding the LSP I still use ALE which, I think, has some of the best UX:
Support for non-LSP linters and fixes (autoformatters mostly). This means I can use the same UI to see diagnostics from both LSP and non-LSP sources. This is really important for me.
A huge collection of integrations with LSP servers and linters. Sometime I discover a linter/LSP for a new file type I’m editing by just invoking
:ALEInfoand seeing a list of suggested integrations.I think all of this is possible with neovim’s new LSP + some configuration on top (like using null-ls for non-LSP linters/formatters). But… it all requires some friction for configuring it right while ALE gives you all of that out of the box.
+1 for ALE, it’s easy and seamless, and comes with an impressively wide language and tools support.
Thanks for the recommendation. I tried neovim but gave up after half an hour of failing to configure its LSP support and after becoming annoyed that they change the undo file format but don’t change the extension so you can’t edit the same file with vim and neovim. I tried ALE and it took about 10 minutes to get it working nicely (well, spread over two days, poking it a bit while I waited for things to build). It does exactly what I want and it’s added a total of under 10 lines to my vimrc to have nice clang-format and clangd integration.
I completely moved from vim/neovim to vis, very satisfied.
I ended up moving off Vis because of the lack of Language Server support. For Rust development, that’s the difference between a ~5s feedback cycle and a ~200ms feedback cycle.
Likewise, though it’s syntax highlighting system is simple, it is pretty bad for Ruby, where every variable ends up highlighted like a method name (since it’s impossible to tell the difference). Turn that off, and method signatures aren’t highlighted anymore.
There’s also helix which I think is shaping up rather nicely.
This looks really nice. I’m definitely going to check it out. Thanks for mentioning it!
How does Helix compare to Kakoune?
What are some crustacean experiences with Treesitter?
I tried it out, despite the warnings about instability, for the refactor plugin. Got this Unity codebase to deal with, and nothing else really provided C# refactoring.
The refactoring wasn’t project-wide, which caused some woes, though I could repeat the operations a few fimes in separate files and be happy-ish. The dealbreaker is that Neovim would quite often deny insert mode, as if the buffer setting changed BTS somewhere. Restart, my favorite!
I don’t use treesitter ATM, maybe later.
LSP is also a mixed bag. Very useful and works nice on my heirloom-grade laptop, even for Unity, but on my desktop it buffers up syntax errors for nearly every keypress and flushes them out so slowly I can jump to Unity and run the unit tests by the time LSP’s done complaining. Sometimes an error is left lingering.
This is with the same config on both machines, and OS load is always less than you’d imagine, so it’s just weird. Even mono should be the same version.
No regrets; C# needs this stuff so bad it’s worth the trade-off.
For typescript it was a game changer. Syntax highlighting in vim never looked quite right, especially in a side-by-side comparison with VSCode.
I also find the neovim ecosystem to be rich and full of new plugins because of things like tree-sitter support. There’s an entire section dedicated to treesitter enabled colorschemes on neovimcraft: http://neovimcraft.com/?search=tag:treesitter-colorschemes
FWIW I hit the insert mode bug without treesitter. For the first time, even. Guess it was the wrong tree(sitter?) I was barking up, because of https://github.com/nvim-telescope/telescope.nvim/issues/82#issuecomment-854596669
Treesitter might be laggy enough or something to trigger the problem more often. Testing that fix now, and maybe I can give Treesitter another shot soon!
Could you expand on this? I would expect C# to be the language with best refactoring tools, given that both JetBrains (Resharper & Rider) and Microsoft (Roslyn) have been working on them for more than 10 years at this point.
Not if neovim is your goal. The solutions from jetbrains and ms are proprietary
This is factually wrong about ms.
Roslyn is MIT licensed, omnisharp makes it speak LSP. For refactors specifically, I’d be surprised if there isn’t non-editor tooling to apply Rosly analyzers as project-wide refactors.
Sure. However actually using omnisharp is another matter. Its definitely not on par with the experience inside of visual studio itself. For example vscode which uses omnisharp provides a pretty demonstrably second class experience compared with rider and visual studio proper. And even then that experience is better than what you get from lsp c# in neovim.
An example of this breakdown is that msbuild integration with visual studio is on a whole other level compared to what omnisharp can handle
What @Kethku said.
I did find this one refactoring plugin
vim-refactorthat pulled in a bunch of library-like stuff, less surprisingly conflicted with some of my maps, and didn’t do c# properly in the end.That’s why Treesitter seemed so appealing. I’m sure it’s not such a turd as my experience was, but I also have work to do beside debugging 0d plugins ;)
I do really look forward to trying it out again, but I’m happy with my LSP setup (despite the error stuff!) and able to be productive now.
I still don’t understand something I believe. Roslyn is a very mature tool to do analysis and transformation of C# code. Using tree sitter for refactors (which knows only syntax) is like parsing html with regexes, only one level up: using syntax analysis for semantic transformations.
I would be surprised if no-one has glued Roslyn to vim, and indeed folks seem to have done that? https://github.com/OmniSharp/omnisharp-vim
If, despite all this, “refactoring C# in vim” is still an unsolved problem, then there’s an opportunity for a fairly easy, fairly popular OSS project here. All the hard work of actually doing refactors has been done by Microsoft. What’s left is the last mile of presenting what Roslyn can do in an editor.
Maybe my “repeat in multiple files” is because of syntax being the wrong layer? I’m really not 100% sure!
It was palatable, and got the job done, and the dealbreaker was something else.
I do have OmniSharp running, but I haven’t seen anything related to proper refactoring in Neovim with it. I could look again and verify I have the latest version, though I did take a quick look before my Treesitter journey.
It would be beyond awesome if more native refactoring existed, but I do believe it’s more of an opportunity than an existing feature.
Current OmniSharp-vim maintainer here. All of the OmniSharp-roslyn code actions are available in OmniSharp-vim. OmniSharp-vim doesn’t actually use LSP, as both OmniSharp-vim and OmniSharp-roslyn are older than the protocol.
However the OmniSharp-roslyn server does have an LSP “mode” and so is usable without OmniSharp-vim using vim LSP plugins or neovim native LSP. I would expect all code actions to be available via LSP too but I don’t know.
I’m curious to know what kind of server-based refactorings we’re talking about exactly.
Hi! And thanks for your maintainership! :)
My use case is/was simple: given a code base, rename methods so they’re renamed everywhere. The start of the rename can be a method definition or a usage, and everything will be figured out. Not sure if that’s possible, even, just a wishlist thing ;)
I haven’t needed to touch constructor (or other method) argument refactoring, and I’m sure the Treesitter refactor plugin has nothing for this, but could be useful.
In OmniSharp-vim you can do
:OmniSharpRenameTo NewSymbolNameon either the definition or a usage and it will be renamed everywhere in the solution.Here’s a demo on the OmniSharp-roslyn codebase. The first 60 seconds are the server warming up (it’s a big solution):
https://asciinema.org/a/gd6GGiGGtcXjBsXoY0UKrqluB
TIL! Thanks! Now I got a config with treesitter that disables the refactoring prompt in c# in favor of an autocmd map for omnisharp :)
Edit: yet to see what needs to be reloaded to get rid if the “does not conrain a definition (though it sure does lol!)” error, but still this is good news :)
Edit2: jumping the gun here,
:LspRestartseems to be good enough.Right, if you’re using LSP and OmniSharp-vim together, you’ll have to find ways of keeping the servers synchronised, because you’re running multiple instances.
Yeah, it’s a bit messy but most often only when autocompleting. I approach my neovim pretty much by fixing things as they start to annoy me too much or cause a productivity hit.
Maybe I’ll get that thing sorted some day, but I’m fine for now :)
I’ve been on a similar journey going from VSCode to neovim. I’m using a very different set of plugins, but not too different from the author. I’ve had a great experience with coc, particularly coc-eslint and coc-tsserver for my LSP needs!
It would be great if there was one place to find examples of these frankinvim configs. With all these features neovim could be a drop-in replacement for someone coming from VSCode or sublime.
A cleaner separation between the processing engine and the UI is one of the more important neovim-over-vim improvements to me. While I suspect the audience here tend to use the terminal emulator path, are there any other daily-driver/heavy users that use any of the alternative UIs?
I use Firenvim on a daily basis, does that count? :^)
I think most windows users prefer using a Neovim GUI (probably Neovim-Qt since it’s bundled with neovim on that platform) because the windows terminal is not very nice to use. I’ve tried most of the linux GUIs and even though some are really nice (Goneovim is my favorite) I still prefer using a terminal. I find that GUIs don’t offer much over just using a terminal (yet?).
I remember you built your own Neovim GUI that integrates with Arcan, does it do anything special?
Indeed. I worked through that list for more interpretations of the documentation (~2.5 years ago) and got the feeling that most started and either gave up, or got to the PoC stage and for some reason stopped before getting to the more complex bits. Msgpack by trial-and-error is quite painful, especially in C.
There’s only one real thing arcan-nvim does “special” right now and that is the integration to “universal load/save” (which is a riff on how drag-drop, cut-paste works). The point of that is I can dynamically send it descriptors and get copies of the current buffer. This lets Pipeworld use it as a cell in a pipeline, so whenever a dependent part of the pipeline or other expressions use it, the active vim buffer will be snapshotted and used. Then it can be used as a building block for making REPLs out of anything. The one I’m testing against for the moment is
(nvim-arcan| latex | apdf | nvim-arcan), so a native arcan-tui application, a “isatty()” legacy terminal program, a native arcan graphical program and back to nvim.What I started it for was testing the arcan-tui (ncurses replacement) API and the server-side text rendering. The real ‘meat’ is the multigrid / popup integration that still isn’t finished. The point of that would be that completion popups works as discrete windows in the WM space, and that, for instance,
:vswould actually give a logically new window that the window manager would understand and treat as vertical-split and integrate with the current policy.That’s exactly what I do with Nwin. You’re going to need the ext-win extension for this, which is far from ready for now.
Your anchor tag for “incremental parsing library” is broken.
Thank you for the Telescope and Treesitter recommendations.
Thanks, I’ve fixed it.