this post was submitted on 04 Dec 2024
36 points (95.0% liked)

Neovim

2195 readers
2 users here now

founded 2 years ago
MODERATORS
 

Honestly... everybody should try out neovim for at least a week. I mean like... fully commit to it.

It's just amazing how fast and light on resource usage it is, compared to vscode.

For reference: I just opened qmk_firmware which has a shit load of clang code and files. Guess what, neovim doesn't even break a sweat, while vscode almost burns my CPU.

top 22 comments
sorted by: hot top controversial new old
[–] dm319@feddit.uk 2 points 6 days ago (1 children)

Oh wow, the whole thread is just people suggesting alternatives!! OP - enjoy your neovim and don't listen to the rest. It's a terrific editor and will be around for many decades more.

[–] ad_on_is@lemm.ee 1 points 6 days ago

I really do enjoy it. It's also a lot of fun to tweak it to my likings and needs.

[–] CheesyFox@lemmy.sdf.org 6 points 1 week ago (1 children)

tried it. Now i have ptsd after attempting to config it. that's why i use helix, seems to work best with minimal configuration. Kakoune makes the most sence out of its keybind paradigm tho

[–] zygo_histo_morpheus@programming.dev 1 points 1 week ago (1 children)

Out of curiosity, what have you had trouble with config wise? I've been using vm/neovim for long enough that I can't relate to the setting up for the first time process anymore. Is it basic stuff or things like adding lsp?

Helix does come with more bells and whistles out of the box so it's great if you don't feel like tinkering with your setup. Couldn't be me, I love that shit!

[–] CheesyFox@lemmy.sdf.org 3 points 1 week ago (1 children)

I was dumb and spoiled by vscode, i wanted to integrate a task runner and a debugger. They both worked kinda shitty compared to what vscode does and i disliked how bloated the config was. Now i simply use GDB as the debugger and Just as the task runner, stickitg to helix more because of the keybinds, integrated tree sitter and other stuff.

I also love to tinker the environment i work in to my liking (love me my gruvbox hyprland), but i'm kinda not a fan of doing everything from scratch, and pre-made configs for nvim either give me agoraphobia by how huge they are, or are too barebones. Helix just clicked for me, because it offers everything necessary out of the box, while allowing to tailor the rest to your liking. Also, because of its editing model which is supperior.

[–] zygo_histo_morpheus@programming.dev 2 points 1 week ago (1 children)

Debugging is kind of a weak point in vim to be honest, there is a plugin called termdebug which comes bundled with vim that can do gdb debugging ok, but anything more complicated mostly just feels like a lot more work and a bit more jank than just using vscode.

I use just as well, it's a more vimy approach than something more tightly integrated so that makes sense.

Helix is nice, but I don't think I could leave behind some of my vim plugins, fugitive in particular is an integral part of my git workflow. Haven't used the kakoune editing model enough to really decide if I think it's better than vim personally.

[–] CheesyFox@lemmy.sdf.org 2 points 1 week ago

oh, never tried fugtive. I just made a keybind that opens lazygit inside of a helix buffer :D

[–] 0x01@lemmy.ml 4 points 2 weeks ago (4 children)

Neovim is genuinely great, but I miss full integrated multicursor support, none of the multicursor libraries quite work seamlessly, I also miss the easily made javascript extensions every time I dive into lua

On the other hand dropping mouse usage entirely is a good little boost to productivity

For me using the nvim extension inside vscode was the sweet spot

[–] xigoi@lemmy.sdf.org 5 points 2 weeks ago* (last edited 2 weeks ago)

I find Lua much more pleasant to code in than JavaScript.

[–] ad_on_is@lemm.ee 4 points 2 weeks ago (1 children)

Isn't this multicursor plugin one of the best, compared to, for exampme, VSCode?

https://github.com/mg979/vim-visual-multi

also :%s/findStr/replaceStr/g gives a live preview too.

[–] desipenguin@programming.dev 2 points 1 week ago

:%s/findStr/replaceStr/g

has been around before neovim

[–] SaintWacko 1 points 2 weeks ago

This is the way. Best of both worlds

[–] GissaMittJobb@lemmy.ml 1 points 1 week ago

How does the nvim-extension compare to vscodevim?

[–] 1984@lemmy.today 2 points 2 weeks ago (1 children)
[–] ad_on_is@lemm.ee 1 points 2 weeks ago (1 children)

I have it installed, but hadn't had the chance totry it productively.

[–] 1984@lemmy.today 1 points 1 week ago* (last edited 1 week ago) (1 children)

I think that one is more of a VS code replacement (it will be, in time). It's just so fast and it's vim mode is excellent.

I used neovim a lot before and still do in the terminal, but zed is faster and smoother for code editing actually.

[–] 80avin@programming.dev 1 points 1 week ago (1 children)

If you are open to GUI editors, have you tried neovim frontends, like neovide ?

[–] 1984@lemmy.today 1 points 1 week ago

Yeah I liked it a lot too. Fun with the graphical effects and felt smoother than neovim in terminal for me.

[–] Aurenkin@sh.itjust.works 1 points 2 weeks ago (1 children)

Welcome, friend! I mostly use JVM languages at work these days which makes me sad because Neovim isn't so great for them. It really is such a great editor though. It's great fun seeing how people customise it as well.

[–] ad_on_is@lemm.ee 2 points 2 weeks ago (1 children)

Lol.. I also spent the last week in customizing, going throuh almost all distros, until I found LazyVim to be the most vanilla one, with sane defaults and a great documentation.

[–] moseschrute@lemmy.world 1 points 2 weeks ago (1 children)

I’m using LunarVim, but LazyVim looks similar. I wonder how they compare. I found LunarVim to be a good starting point, but I’ve customized it quite a bit at this point.

[–] ad_on_is@lemm.ee 3 points 2 weeks ago* (last edited 2 weeks ago)

For me, LunarVim feels more like NVChad, with it's own set of options to control neovim... I'm honestly not a huge fan of this approach.

lvim.builtin.lualine.sections.lualine_c = {...}

I prefer the "lazy" way using plugin files, with the lazy notation, since it feels more agnostic.