Following the discussion in #573 after iamcco/markdown-preview.nvim was removed, let's continue this here.
I think plugins that either have nvim in their name or are unique (do not have an equivalent Lua / Neovim version) should be allowed. Of course they have to work for Neovim (should not be made with Vim9Script). This can be made more strict by requiring a minimum number of stars or a similar metric. Apart from markdown-preview.nvim, another example would be copilot.vim which works for both Vim and Neovim.
In that case, this rule should probably be added to CONTRIBUTING.md. What do you think?
cc @ofirgall
Originally created by @smjonas on GitHub (Oct 11, 2022).
Original GitHub issue: https://github.com/rockerBOO/awesome-neovim/issues/574
Following the discussion in #573 after `iamcco/markdown-preview.nvim` was removed, let's continue this here.
I think plugins that either have `nvim` in their name or are unique (do not have an equivalent Lua / Neovim version) should be allowed. Of course they have to work for Neovim (should not be made with Vim9Script). This can be made more strict by requiring a minimum number of stars or a similar metric. Apart from `markdown-preview.nvim`, another example would be `copilot.vim` which works for both Vim and Neovim.
In that case, this rule should probably be added to `CONTRIBUTING.md`. What do you think?
cc @ofirgall
I think it would be useful to lay down what the goal of this repo is. There are many valid answers here; some that I can think of:
List of plugins that are made specifically for Neovim
List of plugins written in lua
List of all plugins that support Neovim
List of all plugins that work "well" with Neovim (anecdotally I've heard of some vim plugins that run on both but the Neovim implementation has some issues)
Currently the the goal is 1, but I suspect that most of the users that visit this list think of it as 3/4 (i.e. what plugins are available?) Now that vim 9 is released and the two projects are diverging more, I do think there's a stronger case that we as a community need a list of "all plugins that support Neovim," whether that's this list or something else.
A related proposal: if there are some qualities that people particularly care about (written in lua, written specifically for Neovim), perhaps we could add some sort of icon or tag system?
<!-- gh-comment-id:1274857066 -->
@stevearc commented on GitHub (Oct 11, 2022):
I think it would be useful to lay down what the goal of this repo is. There are many valid answers here; some that I can think of:
1. List of plugins that are made specifically for Neovim
1. List of plugins written in lua
1. List of all plugins that support Neovim
1. List of all plugins that work "well" with Neovim (anecdotally I've heard of some vim plugins that run on both but the Neovim implementation has some issues)
Currently the the goal is 1, but I suspect that most of the users that visit this list think of it as 3/4 (i.e. what plugins are available?) Now that vim 9 is released and the two projects are diverging more, I do think there's a stronger case that we as a community need a list of "all plugins that support Neovim," whether that's this list or something else.
A related proposal: if there are some qualities that people particularly care about (written in lua, written specifically for Neovim), perhaps we could add some sort of icon or tag system?
Specifically, originally, was that we'd list Neovim specific (plugins that don't work on Vim) as other awesome lists (VimAwesome) exists for plugins that work for Vim.
Lua is a big component, as well as using Neovim specific APIs.
You could use Lua inside Vim, if you include Lua inside your Vim build. This makes it possible for some plugins to work in both Vim and Neovim and use Lua. Also, there are other languages and runtime supported via like Python, Node.js, Elixir, Go, Rust and others, that can be full plugins and be specific to Neovim.
The size of this list currently is already quite large for just Neovim specific plugins that only work in Neovim. Adding all the plugins that work for Neovim and Vim would add possibly thousands of new plugins. I feel having the specific marker of Neovim specific is a unique perspective that people utilize.
I believe there is some quality in having a list that includes both Neovim and Vim plugins, but I do not think this is the place for that. Vim Awesome website includes both Neovim and Vim plugins and has been around longer.
There are multiple websites that use this list to inventory the current plugins. Could be a starting point to creating a better index of plugins for Vim9, Vim and Neovim, with appropriate distinction.
<!-- gh-comment-id:1275103005 -->
@rockerBOO commented on GitHub (Oct 11, 2022):
Specifically, originally, was that we'd list Neovim specific (plugins that don't work on Vim) as other awesome lists (VimAwesome) exists for plugins that work for Vim.
Lua is a big component, as well as using Neovim specific APIs.
You could use Lua inside Vim, if you include Lua inside your Vim build. This makes it possible for some plugins to work in both Vim and Neovim and use Lua. Also, there are other languages and runtime supported via like Python, Node.js, Elixir, Go, Rust and others, that can be full plugins and be specific to Neovim.
The size of this list currently is already quite large for just Neovim specific plugins that only work in Neovim. Adding all the plugins that work for Neovim and Vim would add possibly thousands of new plugins. I feel having the specific marker of Neovim specific is a unique perspective that people utilize.
I believe there is some quality in having a list that includes both Neovim and Vim plugins, but I do not think this is the place for that. Vim Awesome website includes both [Neovim](https://vimawesome.com/?q=neovim) and Vim plugins and has been around longer.
There are multiple websites that use this list to inventory the current plugins. Could be a starting point to creating a better index of plugins for Vim9, Vim and Neovim, with appropriate distinction.
I think that's a reasonable view, and I do think there's value in having a list of "all the plugins that are built specifically using Neovim features." I think it serves to highlight how the design choices being made within Neovim have enabled a flourishing plugin ecosystem, and it's nice to have those all listed together.
I do agree that it would be great if there were some sort of "master list" of all the extant vim/neovim plugins, with appropriate tags for vim/nvim support, languages used, dependencies required, etc. I don't think any of the current lists/sites support that need. That's something I would love to work on, but absolutely do not have the time for :/
<!-- gh-comment-id:1275484995 -->
@stevearc commented on GitHub (Oct 12, 2022):
I think that's a reasonable view, and I do think there's value in having a list of "all the plugins that are built specifically using Neovim features." I think it serves to highlight how the design choices being made within Neovim have enabled a flourishing plugin ecosystem, and it's nice to have those all listed together.
I do agree that it would be great if there were some sort of "master list" of all the extant vim/neovim plugins, with appropriate tags for vim/nvim support, languages used, dependencies required, etc. I don't think any of the current lists/sites support that need. That's something I would love to work on, but absolutely do not have the time for :/
This repo's name is awesome-neovim rather than awesome-lua-neovim right?
I don't think a good plugin should be excluded just because it supports vim. As more and more difference exist between vim and neovim, looking for a plugin in vimAwesome is getting unsuitable.
My points is:
If a viml plugin has the corresponding lua version, excluding the viml version is all right.
An awesome plugin should be included even if their program language is viml, python or rust. About the concern that this repo may include too many plugins, if they are really awesome, why not?
<!-- gh-comment-id:1275586208 -->
@Weissle commented on GitHub (Oct 12, 2022):
This repo's name is awesome-neovim rather than awesome-lua-neovim right?
I don't think a good plugin should be excluded just because it supports vim. As more and more difference exist between vim and neovim, looking for a plugin in vimAwesome is getting unsuitable.
My points is:
1. If a viml plugin has the corresponding lua version, excluding the viml version is all right.
2. An awesome plugin should be included even if their program language is viml, python or rust. About the concern that this repo may include too many plugins, if they are really awesome, why not?
A point made in #573 was that sometimes there's a Vim plugin that doesn't have a good Neovim-only counterpart.
Maybe a solution for this situation could be a separate list we can maintain at the bottom of the README, where we only put Vim plugins that don't have a Neovim-only alternative. This could have a double function for plugin developers to keep track of what isn't implemented as a Neovim-only plugin yet.
Once a Neovim-only has been added, we would remove the Vim version from the list.
With this the focus is on Neovim-only plugins, Vim plugins that offer functionality lacking in Neovim-only plugins still have some space, and the main list won't grow any longer.
<!-- gh-comment-id:1275725696 -->
@tversteeg commented on GitHub (Oct 12, 2022):
A point made in #573 was that sometimes there's a Vim plugin that doesn't have a good Neovim-only counterpart.
Maybe a solution for this situation could be a separate list we can maintain at the bottom of the README, where we only put Vim plugins that don't have a Neovim-only alternative. This could have a double function for plugin developers to keep track of what isn't implemented as a Neovim-only plugin yet.
Once a Neovim-only has been added, we would remove the Vim version from the list.
With this the focus is on Neovim-only plugins, Vim plugins that offer functionality lacking in Neovim-only plugins still have some space, and the main list won't grow any longer.
Sounds like a good solution @tversteeg, but a user would search for a plugin in the category he expects the plugin would be, it wouldn't make sense to go to the main list category and then search for alternative at the bottom, some users might not know it even exist.
Maybe instead we can add a tag
for viml plugins, that way the user know it's not a Lua plugin and we can track the plugins we need to replace by looking for the tag. We can open issues for replacement too.
<!-- gh-comment-id:1275833028 -->
@ofirgall commented on GitHub (Oct 12, 2022):
Sounds like a good solution @tversteeg, but a user would search for a plugin in the category he expects the plugin would be, it wouldn't make sense to go to the main list category and then search for alternative at the bottom, some users might not know it even exist.
Maybe instead we can add a tag
for viml plugins, that way the user know it's not a Lua plugin and we can track the plugins we need to replace by looking for the tag. We can open issues for replacement too.
Well, I agree with @rockerBOO's philosophy, so I would not like to mix the Neovim-only plugins with Vim plugins. I think the current criteria for the main list are fine.
<!-- gh-comment-id:1275835877 -->
@tversteeg commented on GitHub (Oct 12, 2022):
Well, I agree with @rockerBOO's philosophy, so I would not like to mix the Neovim-only plugins with Vim plugins. I think the current criteria for the main list are fine.
I think the idea of maintaining a list of Vimscript plugins rewrote in Lua would be an opinion and better kept as a separate thing. In some/most cases the Lua plugin isn't a direct improvement, due to if Vimscript was a determent to it's performance or quality.
Like a Lua file manager might generally be better UX due to libuv integration to allow async file opening vs a Vimscript one. But a git client in Vimscript vs Lua, you're waiting on Git to run for either so its more of a UI/UX thing.
I think what is generally wanted is an generalized shortlist of recommended plugins that all work inside Neovim. So possibly Vim9script plugins, Vim/Vimscript plugins, Neovim RPC plugins, Neovim Lua plugins, Neovim Vimscript plugins, Neovim Vimscript9 plugins.
This list has grown into a collection of possibly awesome plugins and showing a lot of them. This allows for a list to be made of all actively updated plugins for Neovim, specifically targeting Neovim. To maintain a shortlist requires an opinion and less plugins would be relevant.
I think everyone should be able to have their own list of recommendations of plugins. If you make one, we can add them to this list. I personally would love to see that. Having to sieve through their dotfiles to find their plugins and then to infer if they are using them all. They could make a shortlist of plugins they enjoy. Maybe even could be a plugin that generated a list of their plugins, that they can filter out the ones they like and use and make a list of their recommendations.
Plugin idea for saving recommendations.
(Like, query packer.nvim for all the plugins installed and then show that as a list. The user can then check different items and items can possibly be cached based on the categorization (let's say the categories and items on this list). The checks are cached so they don't have to update them every time. Then a markdown file is created. The user can set the markdown file location. I would be down for helping with this.)
Hopefully that perspective is understandable. I feel there is value in what you're proposing but the issue of size of this list comes in as it has been mentioned quite a bit. I would be down for promoting popular personal recommendations for like a "new to Neovim, try these short list recommendations" or something.
<!-- gh-comment-id:1276533203 -->
@rockerBOO commented on GitHub (Oct 12, 2022):
I think the idea of maintaining a list of Vimscript plugins rewrote in Lua would be an opinion and better kept as a separate thing. In some/most cases the Lua plugin isn't a direct improvement, due to if Vimscript was a determent to it's performance or quality.
Like a Lua file manager might generally be better UX due to libuv integration to allow async file opening vs a Vimscript one. But a git client in Vimscript vs Lua, you're waiting on Git to run for either so its more of a UI/UX thing.
I think what is generally wanted is an generalized shortlist of recommended plugins that all *work* inside Neovim. So possibly Vim9script plugins, Vim/Vimscript plugins, Neovim RPC plugins, Neovim Lua plugins, Neovim Vimscript plugins, Neovim Vimscript9 plugins.
This list has grown into a collection of possibly awesome plugins and showing a lot of them. This allows for a list to be made of all actively updated plugins for Neovim, specifically targeting Neovim. To maintain a shortlist requires an opinion and less plugins would be relevant.
I think everyone should be able to have their own list of recommendations of plugins. If you make one, we can add them to this list. I personally would love to see that. Having to sieve through their dotfiles to find their plugins and then to infer if they are using them all. They could make a shortlist of plugins they enjoy. Maybe even could be a plugin that generated a list of their plugins, that they can filter out the ones they like and use and make a list of their recommendations.
Plugin idea for saving recommendations.
(Like, query packer.nvim for all the plugins installed and then show that as a list. The user can then check different items and items can possibly be cached based on the categorization (let's say the categories and items on this list). The checks are cached so they don't have to update them every time. Then a markdown file is created. The user can set the markdown file location. I would be down for helping with this.)
Hopefully that perspective is understandable. I feel there is value in what you're proposing but the issue of size of this list comes in as it has been mentioned quite a bit. I would be down for promoting popular personal recommendations for like a "new to Neovim, try these short list recommendations" or something.
Vim plugin must have at least X stars. (I thought about 1k stars but it might be too rough)
Vim plugin would be removed when a Lua alternative is added to the list.
Vim plugin must be tagged with a VimL icon.
If it would get out of control we can always revert this decision.
By the end of the day this list is the goto list when searching for a nvim plugin. I added markdown-preview.nvim because my roommate didn't find my markdown preview plugin, and said glow.nvim wasn't good enough, he settled on a less polished plugin because a better plugin didn't exist in the list just because its written in VimL.
<!-- gh-comment-id:1279925918 -->
@ofirgall commented on GitHub (Oct 16, 2022):
Can't we just make rules to restrict vim plugins?
Something like this:
- Vim plugin mustn't have a Lua alternative.
- Vim plugin must have at least X stars. (I thought about 1k stars but it might be too rough)
- Vim plugin would be removed when a Lua alternative is added to the list.
- Vim plugin must be tagged with a VimL icon.
If it would get out of control we can always revert this decision.
By the end of the day this list is the goto list when searching for a nvim plugin. I added `markdown-preview.nvim` because my roommate didn't find my markdown preview plugin, and said `glow.nvim` wasn't good enough, he settled on a less polished plugin because a better plugin didn't exist in the list just because its written in VimL.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @smjonas on GitHub (Oct 11, 2022).
Original GitHub issue: https://github.com/rockerBOO/awesome-neovim/issues/574
Following the discussion in #573 after
iamcco/markdown-preview.nvimwas removed, let's continue this here.I think plugins that either have
nvimin their name or are unique (do not have an equivalent Lua / Neovim version) should be allowed. Of course they have to work for Neovim (should not be made with Vim9Script). This can be made more strict by requiring a minimum number of stars or a similar metric. Apart frommarkdown-preview.nvim, another example would becopilot.vimwhich works for both Vim and Neovim.In that case, this rule should probably be added to
CONTRIBUTING.md. What do you think?cc @ofirgall
@stevearc commented on GitHub (Oct 11, 2022):
I think it would be useful to lay down what the goal of this repo is. There are many valid answers here; some that I can think of:
Currently the the goal is 1, but I suspect that most of the users that visit this list think of it as 3/4 (i.e. what plugins are available?) Now that vim 9 is released and the two projects are diverging more, I do think there's a stronger case that we as a community need a list of "all plugins that support Neovim," whether that's this list or something else.
A related proposal: if there are some qualities that people particularly care about (written in lua, written specifically for Neovim), perhaps we could add some sort of icon or tag system?
@rockerBOO commented on GitHub (Oct 11, 2022):
Specifically, originally, was that we'd list Neovim specific (plugins that don't work on Vim) as other awesome lists (VimAwesome) exists for plugins that work for Vim.
Lua is a big component, as well as using Neovim specific APIs.
You could use Lua inside Vim, if you include Lua inside your Vim build. This makes it possible for some plugins to work in both Vim and Neovim and use Lua. Also, there are other languages and runtime supported via like Python, Node.js, Elixir, Go, Rust and others, that can be full plugins and be specific to Neovim.
The size of this list currently is already quite large for just Neovim specific plugins that only work in Neovim. Adding all the plugins that work for Neovim and Vim would add possibly thousands of new plugins. I feel having the specific marker of Neovim specific is a unique perspective that people utilize.
I believe there is some quality in having a list that includes both Neovim and Vim plugins, but I do not think this is the place for that. Vim Awesome website includes both Neovim and Vim plugins and has been around longer.
There are multiple websites that use this list to inventory the current plugins. Could be a starting point to creating a better index of plugins for Vim9, Vim and Neovim, with appropriate distinction.
@stevearc commented on GitHub (Oct 12, 2022):
I think that's a reasonable view, and I do think there's value in having a list of "all the plugins that are built specifically using Neovim features." I think it serves to highlight how the design choices being made within Neovim have enabled a flourishing plugin ecosystem, and it's nice to have those all listed together.
I do agree that it would be great if there were some sort of "master list" of all the extant vim/neovim plugins, with appropriate tags for vim/nvim support, languages used, dependencies required, etc. I don't think any of the current lists/sites support that need. That's something I would love to work on, but absolutely do not have the time for :/
@Weissle commented on GitHub (Oct 12, 2022):
This repo's name is awesome-neovim rather than awesome-lua-neovim right?
I don't think a good plugin should be excluded just because it supports vim. As more and more difference exist between vim and neovim, looking for a plugin in vimAwesome is getting unsuitable.
My points is:
@tversteeg commented on GitHub (Oct 12, 2022):
A point made in #573 was that sometimes there's a Vim plugin that doesn't have a good Neovim-only counterpart.
Maybe a solution for this situation could be a separate list we can maintain at the bottom of the README, where we only put Vim plugins that don't have a Neovim-only alternative. This could have a double function for plugin developers to keep track of what isn't implemented as a Neovim-only plugin yet.
Once a Neovim-only has been added, we would remove the Vim version from the list.
With this the focus is on Neovim-only plugins, Vim plugins that offer functionality lacking in Neovim-only plugins still have some space, and the main list won't grow any longer.
@ofirgall commented on GitHub (Oct 12, 2022):
Sounds like a good solution @tversteeg, but a user would search for a plugin in the category he expects the plugin would be, it wouldn't make sense to go to the main list category and then search for alternative at the bottom, some users might not know it even exist.
Maybe instead we can add a tag
for viml plugins, that way the user know it's not a Lua plugin and we can track the plugins we need to replace by looking for the tag. We can open issues for replacement too.
@tversteeg commented on GitHub (Oct 12, 2022):
Well, I agree with @rockerBOO's philosophy, so I would not like to mix the Neovim-only plugins with Vim plugins. I think the current criteria for the main list are fine.
@rockerBOO commented on GitHub (Oct 12, 2022):
I think the idea of maintaining a list of Vimscript plugins rewrote in Lua would be an opinion and better kept as a separate thing. In some/most cases the Lua plugin isn't a direct improvement, due to if Vimscript was a determent to it's performance or quality.
Like a Lua file manager might generally be better UX due to libuv integration to allow async file opening vs a Vimscript one. But a git client in Vimscript vs Lua, you're waiting on Git to run for either so its more of a UI/UX thing.
I think what is generally wanted is an generalized shortlist of recommended plugins that all work inside Neovim. So possibly Vim9script plugins, Vim/Vimscript plugins, Neovim RPC plugins, Neovim Lua plugins, Neovim Vimscript plugins, Neovim Vimscript9 plugins.
This list has grown into a collection of possibly awesome plugins and showing a lot of them. This allows for a list to be made of all actively updated plugins for Neovim, specifically targeting Neovim. To maintain a shortlist requires an opinion and less plugins would be relevant.
I think everyone should be able to have their own list of recommendations of plugins. If you make one, we can add them to this list. I personally would love to see that. Having to sieve through their dotfiles to find their plugins and then to infer if they are using them all. They could make a shortlist of plugins they enjoy. Maybe even could be a plugin that generated a list of their plugins, that they can filter out the ones they like and use and make a list of their recommendations.
Plugin idea for saving recommendations.
(Like, query packer.nvim for all the plugins installed and then show that as a list. The user can then check different items and items can possibly be cached based on the categorization (let's say the categories and items on this list). The checks are cached so they don't have to update them every time. Then a markdown file is created. The user can set the markdown file location. I would be down for helping with this.)
Hopefully that perspective is understandable. I feel there is value in what you're proposing but the issue of size of this list comes in as it has been mentioned quite a bit. I would be down for promoting popular personal recommendations for like a "new to Neovim, try these short list recommendations" or something.
@ofirgall commented on GitHub (Oct 16, 2022):
Can't we just make rules to restrict vim plugins?
Something like this:
If it would get out of control we can always revert this decision.
By the end of the day this list is the goto list when searching for a nvim plugin. I added
markdown-preview.nvimbecause my roommate didn't find my markdown preview plugin, and saidglow.nvimwasn't good enough, he settled on a less polished plugin because a better plugin didn't exist in the list just because its written in VimL.@thetic commented on GitHub (Oct 16, 2022):
Maybe you should make your own list.
@ofirgall commented on GitHub (Oct 17, 2022):
I guess we can close this issue..