Hacker News new | ask | show | jobs
by gorjusborg 74 days ago
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.
2 comments

Not to talk about the other side of the holy war too much, but one of the things I appreciate about GNU ELPA is it's treated as part of the Emacs distribution and needs to follow all the rules of Emacs proper as a result.
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 <modern editor> 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.

Does ex not count?