Hacker News new | ask | show | jobs
by DogLover_ 1197 days ago
For someone considering trying Neovim, the main obstacle is the abundance of GitHub projects promising an effortless way to get started. This abundance can lead to analysis paralysis, making it challenging to choose a path forward.
5 comments

I just used https://github.com/nvim-lua/kickstart.nvim. I did have my own config but I had it across multiple files and this one is simpler.

Astro is more of an attempt to replicate the full IDE experience. You can just copy-paste the above, and you are going (personally, I don't think nvim should be used like a full IDE, you really don't need the file tree or tabs, nvim has a better system than this).

Seconding this. I recently decided to give neovim a try again and found kickstart.nvim to be a nice starting point. Compared to all my previous attempts to get started with (neo)vím, this felt very understandable and effortless.
> you really don't need the file tree or tabs, nvim has a better system than this

Could you expand on what is that system?

As an amateur vim user, may I ask what is the alternative to using file trees or tabs?
Telescope[1] is pretty central to navigation in Neovim these days. Think Ctrl-P in VSCode, but for any entity in your editor or workspace, not just files. Files in workspace, buffers (open files), ripgrep results, LSP symbols / references, etc. Also provides a live preview of search results without having to open them. Plus easily add results to your quickfix list, making large-scale edits easy.

[1]:https://github.com/nvim-telescope/telescope.nvim

I am not the person you asked, but with Telescope you can check/toggle open buffers very quickly, once you get used to it, its far quicker than using tabs(for open buffers).

I do have nvim-tree installed but I rarely use it as most times I either navigate files from within definition or go to file from imports or use grep or just search to open from Telescope.

Check out TJDevries's videos about Personal IDE and about kickstart nvim, he is a neovim and Telescope maintainer so he highlights is various usage very well.

IMO, when switching to neovim you have to struggle for a week or so to learn its ways than trying to make it identical to VSCode. I did not switch to neovim until I learned basic file navigation through vim emulator on VSCode.As that was the hardest thing for me when I first tried vim/neovim.

Buffers. Telescope.

I remember learning vim and not understanding how people used it because you couldn't change files. Using buffers, and some kind of search to load files in made it clear.

Telescope is a good option for file search, and this also has grep.

If you are new to vim/nvim in general give https://www.lunarvim.org/ a try. Most things should just work / are easy to set up.

If you already have some experience and want to configure your own this is a great scaffold to build your own thing: https://github.com/LunarVim/nvim-basic-ide

I found it much easier to install a list of twenty plugins myself.

The problem I had with these projects is that in order to use them, you first have to read the plugin documentation before understanding how to use it.

I used these projects to check what plugins they were using, and then I would go to the plugin Github and check what is does. Then if I like it, I would copy it inside.

LazyVim is relatively transparent and easy to copy in this sense. AstroNvim should be too, now that they both use lazy.nvim for packages.
Indeed, and AFAIK there is normally little configuration beyond plugin installation. But please correct me if I am wrong.
I don't know if I'm contradicting myself but LazyVim has a lot of configuration code in addition, lots of custom keybindings and tweaks to each plugin's config.

But it's transparent in the sense that the lazyvim documentation site reveals how each part is configured.

Don't use any of them.

Use Neovim just as if it were VIM. I've been doing that since I've started using Neovim, the only thing that I missed were encrypted files.

The reason that people use them is to have good LSP integration and completion you need to manage 2-3 or 4 plugins and how they cooperate
It's doable by hand. I wanted to run LSP servers in Docker so I don't need to juggle versions and dependencies and virtual environments on my main machine and nothing out of the box had this. Took a couple of days. It's sad that it's perceived to be so difficult that an extra thing is needed to make it usable. As a result everyone uses those and the actual plugins have poor docs and API, if not that I would've spend less than a day I guess.
I appreciate the fact that I have time and everything to spend two whole days doing that but some others out there are on a clock
if you don't have that time you are already using VS Code ;)
LazyVim has the following completion/lsp plugins loaded (and I've added nothing): cmp-nvim-lsp, mason-lspconfig, mason, neodev, null-ls, nvim-lspconfig, luasnip, and there's more that load on demand.
The best way to deal with such situations in my opinion is flipping a coin and letting everything up to chance. Given the [minimal] stakes, the cost of analysis / paralysis is far greater than any regret from an imperfect config.
All plugins run arbitrary code and basically any and all of them gains access to your entire filesystem, home network, etc. Even if you properly containerize and firewall everything (99% of people won't) it can at very least read your possibly private source code. The stakes are not so small.
I think I was misunderstood, or more likely did not convey the message correctly. Given a set of acceptable configurations that pass your litmus test, there's little - if any - reason to waste effort in deciding which to go with.

I assumed that the commenter had a relatively narrow list of what they deem acceptable, e.g. 2 or 3 or even 4 configurations.

The approach though is more general than this scenario and can be applied in almost every case with low stakes while absolving the person of the regret they might feel for their choice and reduce the time spent deciding in search for "perfection". The goal is to reduce regret and indecisiveness.

I see, I read it as "which do I choose from all the starter templates". I can understand the paralysis, trusting/vetting a whole template is trickier than if you start from blank slate and add plugins one by one as you go and develop intuitions for who are reliable plugin authors that usually don't break your editor etc. But a template is also tempting because more productivity faster, and going plugin by plugin with sometimes poor docs seems daunting.