Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Neovim 0.12.0

github.com

Post reply on HN
Print view View original

221–230 of 271 posts

Re: Neovim 0.12.0

#221

Post by NekkoDroid »

lawn wrote: post #46
flexagoon wrote: post #38

Earlier quoted context omitted.

> how verbose it turned out Verbose? The new plugin manager's interface is literature just vim.pack.add({url}), not sure what is verbose about that

If you want to replicate the lazy features then it will get verbose. Even using a dedicated plugin for lazy loading it's not as tight as lazy.nvim. You may argue that you don't need lazy loading, which is fine, but they're not 1-to-1 compatible.

Nobody said they are 1-to-1 compatible. Also, ideally lazy loading should happen on the plugin side instead of putting it on every user to configure, since neovim natively basically has everything needed for plugins to do the lazy loading of heavy parts[1] and if something is missing it probably is better to add it the hooks for it upstream in neovim instead of the plugin manager so it also works for personal config/plugins.

[1]: https://github.com/neovim/neovim/issues/35562#issuecomment-3...

Re: Neovim 0.12.0

#222

Post by skydhash »

0x1ceb00da wrote: post #172
himata4113 wrote: post #131

I swapped to neovim and never looked back. I don't even have vscode, jetbrains or anything similar installed anymore. AI has made it so so easy to get into neovim and make anything work no matter how obscure it is. The biggest benefit for me which I haven't realized how good it is with tmux and the low low memory usage. I mean I can keep EVERY project I work on open, quickly switch and maintain. No more 10gb memory u…

How many weird terminal bugs do you have in your setup? Eg one that annoys me the most is that pressing esc in insert mode often takes a few seconds to do its thing.

It’s not a bug. The wait times is because the terminal supports escapes codes (which start with an escape character). So most TUI (which put the terminal into a special mode) have a wait time to distinguish between the two (because for the terminal there’s no difference between keyboard events and the software UI). I think it’s configurable in both tmux and vim.

Re: Neovim 0.12.0

#223

Post by dizhn »

eviks wrote: post #220
dizhn wrote: post #208

Earlier quoted context omitted.

I am not saying it's better or you shouldn't use multiple cursors. It does help a lot as opposed to the old way of not seeing what would have been changed. How does multiple cursors work anyway? How do you place them? By search? Is it used for anything other than working on matching text?

Your place them via search, manual click, extending up/down the line, via "match current word" And it's also used for new text entry, not just editing matching text, e.g., add an extra field to each of these 5 arrays

I can picture it better now. Thanks.

Re: Neovim 0.12.0

#224

Post by ghtbircshotbe »

I recently hit the fold level limit, which is hard coded into Vim at 20. I was disappointed that it's the same in neovim. I tried changing the Vim code and compiling from source but apparently it's not that simple because it still doesn't work (although it does behave differently).

I'm hitting the limit due to a system that uses lists of nested rules or decision trees.

Re: Neovim 0.12.0

#225

Post by lawn »

NekkoDroid wrote: post #221
lawn wrote: post #46

Earlier quoted context omitted.

If you want to replicate the lazy features then it will get verbose. Even using a dedicated plugin for lazy loading it's not as tight as lazy.nvim. You may argue that you don't need lazy loading, which is fine, but they're not 1-to-1 compatible.

Nobody said they are 1-to-1 compatible. Also, ideally lazy loading should happen on the plugin side instead of putting it on every user to configure, since neovim natively basically has everything needed for plugins to do the lazy loading of heavy parts[1] and if something is missing it probably is better to add it the hooks for it upstream in neovim instead of the plugin manager so it also works for personal config/…

Yes, my point was that it's probably more verbose because it doesn't have the same feature set

Re: Neovim 0.12.0

#226

Post by hboon »

ray_v wrote: post #138
himata4113 wrote: post #131

I swapped to neovim and never looked back. I don't even have vscode, jetbrains or anything similar installed anymore. AI has made it so so easy to get into neovim and make anything work no matter how obscure it is. The biggest benefit for me which I haven't realized how good it is with tmux and the low low memory usage. I mean I can keep EVERY project I work on open, quickly switch and maintain. No more 10gb memory u…

Ok, this sounds awesome, but do you miss the GUI integrations? like , being able to pop a document open in your editor from the desktop? It just feels like it's hard to nail down your preferred workflow / setup ... but it's likely worth it if you're using it daily! Are there any good visual or video demos of using this type of setup? I'm having trouble picturing what makes people really love this type of TUI-only wor…

> like , being able to pop a document open in your editor from the desktop?

There's a hackish way to do it by watching for Neovim command line commands that start with "/Users/" (change it if you are on other OS).

Your coding agent can probably hack something up based on:

`//Hackish supports drag and drop files into Neovim by examining when command line starts with "/Users/".`

Re: Neovim 0.12.0

#227

Post by cassepipe »

mayli wrote: post #109
cassepipe wrote: post #78

Earlier quoted context omitted.

Forget macros and multi-cursor. (Regex) substitutions from vim's command line replaced 98% of my editing needs and rendered a lot of my vim-fu useless. (Just like searching with / replaced 98% of my navigation) Editing something without having to actually place the cursor anywhere is a killer feature Also neovim can show you your substitutions live, no need for a plugin anymore. It's the default.

Bro, not every guy/girl is a regex master, multi-cursor is a much better UI/UX wysiwyg editor for everyday users.

Sis, substitutions started being useful being I even learned Regex and I have done an incredible amount of edits with the just the bare minimum of Regex knowledge

Re: Neovim 0.12.0

#228

Post by gorjusborg »

qudat wrote: post #135
gorjusborg wrote: post #81

Earlier quoted context omitted.

I agree in principle that absorbing the best from the ecosystem is good. However, anything pulled into core should have a long lifetime and be considered part of the API. This deserves careful consideration, and plugins work really well until it is clear there is a reason to pull something in.

There is zero reason not to include a picker like helix does. I’m gonna guess 90% of everyone running neovim has a picker

I believe we are thinking about different time horizons, and your language and comparison to reveals a lot about unsaid about your reasoning.

I don't think comparison to other editors is a good basis for deciding what should be pulled in. The vi ecosystem was and remains weird to those outside, but in a way that is internally consistent to the usage patterns of its own user over decades.

Also, percentage of users using X feature is also a bad selection criteria for pulling a plugin provided feature, unless that number is 100% and there is little deviation in configuring it. There is very little friction in pulling in a plugin as a user.

So what are some good criteria for absorbing plugin functionality?

- extensions that provide an API for entire ecosystems (plenary, lazy.nvim)

- plugins that add missing features or concepts that are to useful, and timeless to ignore

- plugins that would benefit themselves or neovim by moving to native code

Honestly, the bar for absorbing plugins should be pretty high. There should be a real benefit that outweighs the cost of more maintenance, coupling, and ultimately cost.

The cost of installing plugins is pretty low, and they are great at keeping the core software simple.

Re: Neovim 0.12.0

#229

Post by NekkoDroid »

lawn wrote: post #225
NekkoDroid wrote: post #221

Earlier quoted context omitted.

Nobody said they are 1-to-1 compatible. Also, ideally lazy loading should happen on the plugin side instead of putting it on every user to configure, since neovim natively basically has everything needed for plugins to do the lazy loading of heavy parts[1] and if something is missing it probably is better to add it the hooks for it upstream in neovim instead of the plugin manager so it also works for personal config/…

Yes, my point was that it's probably more verbose because it doesn't have the same feature set

I guess yeah, on me for missing that implication.

But as indicated by my comment in the specific case for lazy loading, the plugin manager is the wrong place to have it. Regarding its other features I am not sure most of them need to be part of the plugin manager either (at least from the "plugin spec" part) and are better suited as extensions to other parts of core neovim (e.g. options for plugins might need better `vim.{o,g}` support for nested objects, unsure). Maybe specifying nested dependencies might make sense to add to `vim.pack`.

All this to say: yea, now it is more verbose, but it doesn't have to be.

Re: Neovim 0.12.0

#230

Post by _bohm »

tovej wrote: post #50
semiinfinitely wrote: post #21

the zig build system is the only thing that actually matters in these notes. nobody maintains a parallel build system for fun—it's a clear signal they're finally pathfinding a way to migrate the core away from legacy c. zig's native interop is basically the only way to do this incrementally without the massive friction of a full rust rewrite. definitely makes nvim feel like a much more serious environment for systems…

Couldn't disagree more. Why move away from solid, mature build systems to something relatively fringe like zig. Sadly, this is the general trend with neovim in general: less focus on stability, more and more focus on shiny new things. If I didn't have an nvim config that I'm used to I would have switched to plain vim ages ago.

Having spent some time with the Zig build system, I genuinely expect this development will make things less fragile than they were with the CMake build.
Post reply on HN