Live data from Hacker News

LazyVim

lazyvim.org

31–40 of 537 posts

Re: LazyVim

#31
post #29
post #21

Earlier quoted context omitted.

copilot works wonderfully inside NeoVim; I use it daily. You are right that some of the more advanced integrations (Chat, direct analysis/explanation) aren't ported though. I use shellgpt in tmux for a (not as good but almost) experience.

Does it really work wonderfully for you? I am often times shocked by how it just can't guess the most obvious completions. Then I jump into VSCode to sanity check, and it works fine there. Talking about tpope's official neovim plugin

Just tagging in for comment OP.

Copilot really does work wonderfully for me, as expected with any AI code completion. I run copilot and coc.vim simultaneously, to be noted. So when I just want to autocomplete a word, it'll be coc.vim, but when I want a whole line/method/etc built I'll let copilot be my copilot.

Re: LazyVim

#32

A bit off-topic, but I wonder how much Copilot/GPT cuts into the market share of editors like vim and emacs. I used emacs for the past few years, but I recently switched (back) to vscode because the Copilot integration is really good. There are a lot GPT integraton packages for other editors, but they don't come close to the deeper integration that vscode has. And of course, vscode will probably get priority treatmen…

I've been using a text editor and a repl forever now and don't see myself adding to the workflow. I don't optimize things that are so far off the critical path of my productivity.

Re: LazyVim

#33
post #3

The other comparable setups: 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.

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.

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

Re: LazyVim

#34
post #3

Earlier quoted context omitted.

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 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 c…

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.

Re: LazyVim

#35

These don't usually take off because people who use vim and emacs are people who insist on customizability and aren't into all the bloat that comes with IDEs. People who want IDEs aren't interested in an editor that lives in the terminal. There is a very limited market for something like this.

I disagree, I think these are helping people see neovim as a an alternative, drop-in replacement for VSCode or other editors with the added benefit of being vim.

I also think once people start using these regularly, they tend to learn more about neovim and vim universe how it can be customised to their needs, this acts as a starting point for many without the need to spend days/weeks setting it up to what they are used to.

And for most it becomes easy to just rely on the maintainers to add new additions via plugins and/or update as and when required without the need to update/break/debug on their own.

Re: LazyVim

#36

A bit off-topic, but I wonder how much Copilot/GPT cuts into the market share of editors like vim and emacs. I used emacs for the past few years, but I recently switched (back) to vscode because the Copilot integration is really good. There are a lot GPT integraton packages for other editors, but they don't come close to the deeper integration that vscode has. And of course, vscode will probably get priority treatmen…

The master plan is to have everybody writing Microsoft Typescript in Microsoft Visual Studio Code using Github (Microsoft) Copilot

Re: LazyVim

#37
post #30

Earlier quoted context omitted.

Aren’t you giving your code away to Microsoft if you use Copilot?

You can now configure it to not use your code for learning

But it has to use your code for inferencing, doesn't it? So it is sending it to someone.

I see this being a blocker at a lot of places. I know in my workplace the infosec people are apoplectic about it and we supposedly have a 'partnership' with OpenAI.

Re: LazyVim

#38

These don't usually take off because people who use vim and emacs are people who insist on customizability and aren't into all the bloat that comes with IDEs. People who want IDEs aren't interested in an editor that lives in the terminal. There is a very limited market for something like this.

There's plenty of people inbetween the extremes. I don't want the bloat but I'm also busy (tired) and don't want to spend a weekend getting my dev env setup. These pre-made environments are great to dip my toes in the water; I get the speed of vim with some of the "batteries included" ergonomics of actual IDEs.

Re: LazyVim

#39
I know it sounds like a pain, but I really am a big advocate for learning how to customize vim (or emacs) yourself. These are great places to start, but the power of terminal editors is that they cater to you at a very personal level. The problem with "IDEs" isn't that they are bulky, it is that they railroad you into doing something a very specific way. Terminal emulators put the custom configuration in your face because that's the point. You should edit color schemes if you don't like them. Select only tools you actually want or will use. Learn native commands (because so many plugins do things that are native and even taught in vimtutor). Turn it into a game if you want. Whatever, it is personalized __for you__, and that's the point. Start here, but make sure to move on and make the editor __yours__

Re: LazyVim

#40
post #28
post #23

Earlier quoted context omitted.

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.

The ruby stuff for vscode isn't quite up to quality and I find I turn a lot of it off. I've had a good time with the fuzzy LSP https://marketplace.visualstudio.com/items?itemName=Blinknli... 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…

> What is irb integration

Stuff like having code locations in irb hyperlink back to the code buffer in another window.

Post reply on HN