Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: