I find that any IDE-type setup in vim causes vim to lose the most important thing, speed. If your movements slow down because of too many plugins, the experience is far worse than in a normal non-modal IDE.
I don’t mind slowdowns as long as they are synchronous and deterministic. But most IDEs and IDE-like plugins work asynchronously, so you have to wait and sync all the time. I think that this async-all approach gains technically but loses methodically, so I stick to basic editing. Ymmw.
What I would like to try is an asynchronous non-inplace helper. Like a side panel or a bg overlay to the right-ish that understands what you’re doing and suggests identifiers, reference snippets, full type info, etc. Like the whole page in a smaller font dedicated to what’s under the cursor. Then you could choose what to type into the code, or ignore it because I already know that. I don’t mind typing if it doesn’t require too much attention.
Another thing I’d like to try is mobile-style typing suggestions. First - semi-transparent popups above words in case there’s a typo or an obvious continuation, applied via M-CR. Second - 3-5 most obvious next tokens to insert without even starting to type. Like in
let start = new Date
let date|
Suggests [“=“]. When you choose it, it suggests [“new”, “start”, “Date”, “undefined”]. I bet one could type pages with this alone.
This might work nicely with any editing model, imo.
there is a somewhat hacky way to accept just a word, to my understanding, since copilot.vim allows you to access the raw text that's being suggested. try out the snippet in the linked comment:
It’s a similar job, but a different value. Copilot writes code you don’t know yet (supposedly), while this speeds up typing what you know you’d like to type. Both modes could be useful, I think.
I really haven't experienced this. There was one time i noticed vim slow down, and that was related to a relative line number bug specific to Mac, but that was fixed a while ago. I've used many of the ide type neovim premade configs, and i use my own which has a lot going on. None seem slow to me. Guess it has been a while since I've used a vanilla config. Full ide setups in neovim don't seem slow to me, especially compared to other full ides or vs code.
I also haven't experienced this much. I use the lazy loading functionality for vim-plug, along with async where I can. My neovim starts up in only a few milliseconds and avoids loading most plugins until I open specific file types or use a specific command.
One more thing. You can start neovim with different configs, so if you wanted to launch neovim with a super light config, it is possible to have both. Need to do some trickery with env vars, but it's not hard.
> I find that any IDE-type setup in vim causes vim to lose the most important thing, speed. If your movements slow down because of too many plugins, the experience is far worse than in a normal non-modal IDE.
Um… the word any is doing a lot of work in this sentence. I never had this problem on a 7 year-old iMac. I tried using VS Code on the same machine with just a few plugins on small projects and because it's an Electron app, I'd get frustrated and switch back to Neovim. VS Code has come a long way but it's no Neovim.
The beauty of new plugin managers like Lazy.nvim [1] is you could have 30 plugins configured but Lazy doesn't load all of them at once. In fact, it doesn't load any of ones you don't need and when they do load, it's asynchronous.
Plugins on Neovim run on separate threads from the editor itself, another reason we don't get those slowdowns you spoke of.
I can't comment on any implementation details, but at least with LunarVim (which I use for daily coding), a slowdown when interacting with LSP is very noticeable. Some others have attested to this on a GitHub issue.
I'm not doubting your experiences with the lack of a slowdown, but there is truth that others do experience it. That might be more of a problem with LunarVim itself rather than Vim, but how likely am I (as someone who would like to avoid what he calls "config hell") or other newcomers to avoid whatever pitfalls there are, if a distribution designed for ease of use by people who know better fall into them?
After re-reading my comment, I think it was somewhat unfair. LunarVim is still the best and most comfortable code editing solution for me and the performance hit isn't that bad.
The point I made about config hell might also be a bit out of place in this subthread since ease of use wasn't brought up explicitly in the comment chain I'm replying to (although distributions aiming for ease of use were mentioned).
What is this speed you speak of? I developed in vim for a decade, then eMacs for another decade, before finally moving to VS Code. I’ve never been as productive with vim/eMacs as I am with Code, or Visual Studio proper / XCode when I have cause to sue them.
Having used all three myself I bounced off VS Code hard because getting a usable Ruby setup with all the fixings like irb integration and sorbet ls was multiple days of frustration and still not working right compared to it just working out or the box with Doom Emacs. What’s the happy path that made VS Code work so well for you? I’m curious in case I did it wrong.
I think sorbet hasn't got the critical mass of devs using it so tooling is hit or miss. And I personally don't like it even though I'm well onboard with typescript.
What is irb integration? I tend to avoid that kind of thing and just do it in the terminal regardless of which editor I'm using.
May I ask what makes you more productive with vscode? Coming from decades of emacs I'm always wondering if I should try it. If anything because emacs is a huge time sink. You can get lost customizing it to your needs and forget that what you needed in the first place was get the work done.
It's basically all the benefits of an expertly configured and finely tuned emacs setup, except maintained by other open source developers so competently that your only time spent configuring your editor is clicking "Install Plugin" the first time you open a file written in the language/framework you use. Sensible defaults, batteries included.
The only downside is that as a web tech app it can have some noticeable latency. But on a beefy dev laptop or workstation the difference shouldn't be noticeable.
Maybe for your needs. When I worked as a game developer was amazing for visual debugging gigabytes of runtime data generated by a game engine with millions of lines of code. I could endlessly click through class hierarchies to see what interconnections arise at runtime, and setup all kinds of complicated breakpoint conditions. Obviously you can do all this with gdb or lldb as well, but in my experience it never approached the productivity boost of a graphical debugger.
Visual Studio is a bit shit outside of games, .net, or windows desktop software though.
This is not a direct response to your experience but a little off topic but lazyvim uses lazy.vim which is a modern plugin manager that lazy loads plugins/extensions, it also loads plugins on demand instead of loading them all together at startup from your config. It also can lazy-load plugins based on events, keymaps, filetypes etc
NvChad: https://github.com/NvChad/NvChad
AstroNvim: https://github.com/AstroNvim/AstroNvim
LunarVim: https://github.com/LunarVim/LunarVim
Never got into any of these, but I love that they showcase what's possible.