So it needless to say that the category is quite bloated, which isn't so suprising considering how ambiguous the name is (is this for Lua development in Neovim? Lua development for Neovim? If for, are libraries included? and so on).
Fennel is kinda similar and is less bloated only due to Fennel being less popular. Here is what it contains:
Probably miscategorized plugins which happen to kinda fall under Fennel (only one again, Olical/conjure)
I propose the following:
Create a separate Library category (maybe it also should have some tags like [Lua] and [Fnl]?)
Move plugins for general Lua development into Programming Languages Support/Lua
Move some plugins to more suitable categories
Problems not covered:
Plugins for Neovim Lua development. Should they belong to Programming Languages Support/Lua? Maybe narrow Neovim Lua Development to only those kinds of plugins?
Fennel integrations. Where do they belong? Programming Languages Support/Fennel? Maybe some new category? I don't quite like the idea of narrowing Fennel because similar integrations for other languages may arise (I'm currently developing this kind of plugin actually).
Obviously open for discussion :3
Originally created by @sukineco on GitHub (May 28, 2026).
Original GitHub issue: https://github.com/rockerBOO/awesome-neovim/issues/2336
Originally assigned to: @rockerBOO, @Penaz91, @DrKJeff16 on GitHub.
_Neovim Lua Development_ contains the following sorts of things:
- Libraries (i.e. [`saghen/blink.lib`](https://github.com/saghen/blink.lib), [`nvim-lua/plenary.nvim`](https://github.com/nvim-lua/plenary.nvim), [`kkharji/sqlite.lua`](https://github.com/kkharji/sqlite.lua))
- Plugins for general Lua development (i.e. [`folke/lazydev.nvim`](https://github.com/folke/lazydev.nvim), [`milisims/nvim-luaref`](https://github.com/milisims/nvim-luaref))
- Plugins for Neovim Lua development (i.e. [`bfredl/nvim-luadev`](https://github.com/bfredl/nvim-luadev), [`nvim-mini/mini.nvim#mini.doc`](https://github.com/nvim-mini/mini.nvim/blob/main/readmes/mini-doc.md), [`nvim-mini/mini.nvim#mini.test`](https://github.com/nvim-mini/mini.nvim/blob/main/readmes/mini-test.md))
- Probably miscategorized plugins which happen to kinda fall under _Neovim Lua Development_ (i.e. [`svermeulen/vimpeccable`](https://github.com/svermeulen/vimpeccable), [`OXY2DEV/helpview.nvim`](https://github.com/OXY2DEV/helpview.nvim))
So it needless to say that the category is quite bloated, which isn't so suprising considering how ambiguous the name is (is this for Lua development _in_ Neovim? Lua development _for_ Neovim? If _for_, are libraries included? and so on).
_Fennel_ is kinda similar and is less bloated only due to Fennel being less popular. Here is what it contains:
- Libraries (only one though, [`udayvir-singh/hibiscus.nvim`](https://github.com/udayvir-singh/hibiscus.nvim))
- Fennel integrations (i.e. [`aileot/nvim-thyme`](https://github.com/aileot/nvim-thyme), [`Olical/nfnl`](https://github.com/Olical/nfnl), [`rktjmp/hotpot.nvim`](https://github.com/rktjmp/hotpot.nvim))
- Probably miscategorized plugins which happen to kinda fall under _Fennel_ (only one again, [`Olical/conjure`](https://github.com/Olical/conjure))
I propose the following:
- Create a separate _Library_ category (maybe it also should have some tags like _`[Lua]`_ and _`[Fnl]`_?)
- Move plugins for general Lua development into _Programming Languages Support/Lua_
- Move some plugins to more suitable categories
Problems not covered:
- Plugins for Neovim Lua development. Should they belong to _Programming Languages Support/Lua_? Maybe narrow _Neovim Lua Development_ to only those kinds of plugins?
- Fennel integrations. Where do they belong? _Programming Languages Support/Fennel_? Maybe some new category? I don't quite like the idea of narrowing _Fennel_ because similar integrations for other languages may arise (I'm currently developing this kind of plugin actually).
Obviously open for discussion :3
On the second thought, udayvir-singh/hibiscus.nvim is not quite a Library? Or is it? It's a library for writing init file, not plugins.
I saw Integration category being mentioned before (here) and I think it would be a suitable solution for Fennel integrations. UPD: If Integration passes, it could help with unnesting Split and Window via moving out Tmux which allows for further merging with UI; Terminal Integration and Git might also belong here (Git may require splitting Github and Gitlab into their own subsections of Integration which seems fine to me).
Plugins for Neovim Lua development are kinda Programming Languages Support/Lua? Awesome Emcas does the same thing with ELisp but it's obviously a different case. Maybe some Programming Languages Support/Lua/Neovim would fit? UPD: I saw talks about nesting in #1875, parsing point makes absolute sense so maybe additional nesting is a bad idea.
Off-topic. Programming Languages Support should have a separate subcategory for every language. It'd be just more organised and so is easier to navigate through.
Off-topic. Dependency Management has a rather confusing name and all plugins from there could easily be merged into Programming Languages Support.
<!-- gh-comment-id:4570928714 -->
@sukineco commented on GitHub (May 29, 2026):
Okay, some addtions.
1. On the second thought, [`udayvir-singh/hibiscus.nvim`](https://github.com/udayvir-singh/hibiscus.nvim) is not quite a _Library_? Or is it? It's a library for writing init file, not plugins.
2. I saw _Integration_ category being mentioned before ([here](https://github.com/rockerBOO/awesome-neovim/issues/2046#issuecomment-3685589106)) and I think it would be a suitable solution for Fennel integrations. _UPD:_ If _Integration_ passes, it could help with unnesting _Split and Window_ via moving out _Tmux_ which allows for further merging with _UI_; _Terminal Integration_ and _Git_ might also belong here (_Git_ may require splitting _Github_ and _Gitlab_ into their own subsections of _Integration_ which seems fine to me).
3. Plugins for Neovim Lua development are kinda _Programming Languages Support/Lua_? [Awesome Emcas](https://github.com/emacs-tw/awesome-emacs) does the same thing with ELisp but it's obviously a different case. Maybe some _Programming Languages Support/Lua/Neovim_ would fit? _UPD:_ I saw talks about nesting in #1875, parsing point makes absolute sense so maybe additional nesting is a bad idea.
4. Off-topic. _Programming Languages Support_ should have a separate subcategory for every language. It'd be just more organised and so is easier to navigate through.
5. Off-topic. _Dependency Management_ has a rather confusing name and all plugins from there could easily be merged into _Programming Languages Support_.
Also a huge off-topic on colorschemes. If Library passes, Colorscheme Creation could be merged into there which in perspective allows for merging Colorscheme into UI (as proposed in #1875) without additional nesting.
<!-- gh-comment-id:4571149870 -->
@sukineco commented on GitHub (May 29, 2026):
Also a huge off-topic on colorschemes. If _Library_ passes, _Colorscheme Creation_ could be merged into there which in perspective allows for merging _Colorscheme_ into _UI_ (as proposed in #1875) without additional nesting.
Integration category for a lot of sorts of things looks reasonble too, Fennel could be turned into a subcategory
Programming Languages Support/Lua also seems reasonable
All plugins from both Fennel and Neovim Lua Development could be moved into those new categories
<!-- gh-comment-id:4572735200 -->
@sukineco commented on GitHub (May 29, 2026):
# Summary
- _Library_ category for things like [`nvim-lua/plenary.nvim`](https://github.com/nvim-lua/plenary.nvim) looks reasonable
- _Integration_ category for a lot of sorts of things looks reasonble too, _Fennel_ could be turned into a subcategory
- _Programming Languages Support/Lua_ also seems reasonable
- All plugins from both _Fennel_ and _Neovim Lua Development_ could be moved into those new categories
At first value, I feel that a "Library" section is a bit wonky. Some of these plugins to be moved there can be utilized on their own as a standalone plugin.
Will have to think this through later today when I'm free.
A good idea could be a draft PR, like #2311, to have a good idea how things would be ordered.
<!-- gh-comment-id:4579723053 -->
@DrKJeff16 commented on GitHub (May 29, 2026):
At first value, I feel that a "Library" section is a bit wonky. Some of these plugins to be moved there can be utilized on their own as a standalone plugin.
Will have to think this through later today when I'm free.
---
A good idea could be a draft PR, like #2311, to have a good idea how things would be ordered.
At first value, I feel that a "Library" section is a bit wonky. Some of these plugins to be moved there can be utilized on their own as a standalone plugin.
Well, I think "Library" could be just a fallback for library-like plugins if there is no better place for them. Anways it's better than bloating "Utility" even more or placing these plugins in some seemingly unrelated categories.
<!-- gh-comment-id:4582869192 -->
@sukineco commented on GitHub (May 30, 2026):
> At first value, I feel that a "Library" section is a bit wonky. Some of these plugins to be moved there can be utilized on their own as a standalone plugin.
Well, I think "Library" could be just a fallback for library-like plugins if there is no better place for them. Anways it's better than bloating "Utility" even more or placing these plugins in some seemingly unrelated categories.
The "Neovim Lua Development" section has been left a bit to its own devices since I first saw the project (way before I joined the maintenance team).
I think the main objective there is to gather plugins that help "Programming Neovim using Lua" (and not the opposite). In essence all the plugins that:
Aid people in making their own config using Lua, by adding libraries that make less cumbersome to do certain operations (like creating new keymaps in a less verbose manner);
Allowing users to use other dialects (like Fennel) to make their own config files;
Help people building plugins and configs by exposing (for instance via omnicomplete) the internal Lua functions offered by the Neovim Lua APIs;
I think the "Fennel" section was meant to be under "Neovim Lua Development", since Fennel can call Lua functions, but don't quote me on that.
In general:
Whatever plugins are verified to be just about "general lua development", without any specific objective of aiding in coding stuff for Neovim should be moved under "Programming Language Support -> Lua", this should contains generic REPLs, stuff to make LangServers easier to set up, etc...;
Create a section dedicated to "Coding Neovim Plugins", where we can put some stuff:
Plugin Boilerplates/basic structures;
Libraries (like SQLite interfacing, logging libraries, testing libraries, and "anything that shouldn't be written twice");
Anything that would assist users in "Coding Neovim" (as opposed to Coding in Neovim), for instance by exposing the Lua API to the editor itself;
Create a section dedicated to all the "Neovim configuration helpers" that could contain everything that is used by the end user to hide "configuration boilerplate" (like quickly creating new keymaps without using the sometimes cumbersome vim.api.nvim_set_keymap API) or to use other lua-compatible languages for their config.
This should cover most cases that I see happening right now. The only thing that may be a bit wonky is the definition of Library, in case someone is not agreeing with mine (aka "everything that shouldn't be written twice, see plenary.nvim).
I'm available for any question in regard to this matter, I may not respond quickly but I'll try to be as comprehensive as possible when I do.
<!-- gh-comment-id:4586807464 -->
@Penaz91 commented on GitHub (May 31, 2026):
The "Neovim Lua Development" section has been left a bit to its own devices since I first saw the project (way before I joined the maintenance team).
I think the main objective there is to gather plugins that help "Programming Neovim using Lua" (and not the opposite). In essence all the plugins that:
- Aid people in making their own config using Lua, by adding libraries that make less cumbersome to do certain operations (like creating new keymaps in a less verbose manner);
- Allowing users to use other dialects (like Fennel) to make their own config files;
- Help people building plugins and configs by exposing (for instance via omnicomplete) the internal Lua functions offered by the Neovim Lua APIs;
- Assist plugin developers by giving "often necessary" libraries, like SQLite interaction, ready-to-use (or almost) UI components, async support, encrypted storage, etc...;
I think the "Fennel" section was meant to be under "Neovim Lua Development", since Fennel can call Lua functions, but don't quote me on that.
In general:
- Whatever plugins are verified to be just about "general lua development", without any specific objective of aiding in coding stuff for Neovim should be moved under "Programming Language Support -> Lua", this should contains generic REPLs, stuff to make LangServers easier to set up, etc...;
- Create a section dedicated to "Coding Neovim Plugins", where we can put some stuff:
- Plugin Boilerplates/basic structures;
- Libraries (like SQLite interfacing, logging libraries, testing libraries, and "anything that shouldn't be written twice");
- Anything that would assist users in "Coding Neovim" (as opposed to Coding **in** Neovim), for instance by exposing the Lua API to the editor itself;
- Create a section dedicated to all the "Neovim configuration helpers" that could contain everything that is used by the end user to hide "configuration boilerplate" (like quickly creating new keymaps without using the sometimes cumbersome `vim.api.nvim_set_keymap` API) or to use other lua-compatible languages for their config.
This should cover most cases that I see happening right now. The only thing that may be a bit wonky is the definition of Library, in case someone is not agreeing with mine (aka "everything that shouldn't be written twice, see `plenary.nvim`).
I'm available for any question in regard to this matter, I may not respond quickly but I'll try to be as comprehensive as possible when I do.
Yeah, I kinda fully agree with this but I think it's better for "Neovim configuration helpers" to be a subsection. Maybe something like this would work?
Also I think instead of "Fennel" it could be "Third-party Languages Support" or something like this because we already have gpanders/nvim-moonwalk (in "Utility" rn) at very least.
And, kinda off-topic tho, if this kind of structure is fine then here is no place for "Integration"; should I open a separate PR for it? For me at least, "Integration" seems like a good thing.
<!-- gh-comment-id:4586951503 -->
@sukineco commented on GitHub (May 31, 2026):
Yeah, I kinda fully agree with this but I think it's better for "Neovim configuration helpers" to be a subsection. Maybe something like this would work?
```markdown
- Extending Neovim
- Library
- Configuration Helper
- Fennel
```
Also I think instead of "Fennel" it could be "Third-party Languages Support" or something like this because we already have [`gpanders/nvim-moonwalk`](https://github.com/gpanders/nvim-moonwalk) (in "Utility" rn) at very least.
And, kinda off-topic tho, if this kind of structure is fine then here is no place for "Integration"; should I open a separate PR for it? For me at least, "Integration" seems like a good thing.
Configuration is a way of coding the editor in an of itself so there is some overlap and I can see why you'd want to make a subsection out of it.
If there will be a "third party languages support" we risk having all languages mixed up (and making more subsections might break sites that use this repository as their data source)
And, kinda off-topic tho, if this kind of structure is fine then here is no place for "Integration"; should I open a separate PR for it? For me at least, "Integration" seems like a good thing.
Depends on what "integration" will contain and what you mean for such term. Breaking down the problem in smaller chunks is a good idea though, so I would say to hold off on that for now and tackle it in another PR.
<!-- gh-comment-id:4586970358 -->
@Penaz91 commented on GitHub (May 31, 2026):
> - Extending Neovim
> - Library
> - Configuration Helper
> - Fennel
This sounds like a good starting point.
Configuration is a way of coding the editor in an of itself so there is some overlap and I can see why you'd want to make a subsection out of it.
If there will be a "third party languages support" we risk having all languages mixed up (and making more subsections might break sites that use this repository as their data source)
-----
> And, kinda off-topic tho, if this kind of structure is fine then here is no place for "Integration"; should I open a separate PR for it? For me at least, "Integration" seems like a good thing.
Depends on what "integration" will contain and what you mean for such term. Breaking down the problem in smaller chunks is a good idea though, so I would say to hold off on that for now and tackle it in another PR.
Configuration is a way of coding the editor in an of itself so there is some overlap and I can see why you'd want to make a subsection out of it.
Mostly for clarity but maybe placing such plugins just in "Extending Neovim" would be fine.
If there will be a "third party languages support" we risk having all languages mixed up (and making more subsections might break sites that use this repository as their data source)
Adding a separate section for every language then? Also, would "Fennel & Lisp" be a better fit then (I'm just developing a lisp language specifically for Neovim and still not quite sure where to place it because it's not Fennel but spiritually is very similar).
Depends on what "integration" will contain and what you mean for such term.
When I placed Fennel there it was just a bad idea it seems. I think of "Integration" as the "Programming Languages Support" but for external tools (git, github, ai agents, tmux and so on); not quite sure if "Terminal Integration" should be subsection in this case.
<!-- gh-comment-id:4587007445 -->
@sukineco commented on GitHub (May 31, 2026):
> Configuration is a way of coding the editor in an of itself so there is some overlap and I can see why you'd want to make a subsection out of it.
Mostly for clarity but maybe placing such plugins just in "Extending Neovim" would be fine.
> If there will be a "third party languages support" we risk having all languages mixed up (and making more subsections might break sites that use this repository as their data source)
Adding a separate section for every language then? Also, would "Fennel & Lisp" be a better fit then (I'm just developing a lisp language specifically for Neovim and still not quite sure where to place it because it's not Fennel but spiritually is very similar).
> Depends on what "integration" will contain and what you mean for such term.
When I placed Fennel there it was just a bad idea it seems. I think of "Integration" as the "Programming Languages Support" but for external tools (git, github, ai agents, tmux and so on); not quite sure if "Terminal Integration" should be subsection in this case.
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 @sukineco on GitHub (May 28, 2026).
Original GitHub issue: https://github.com/rockerBOO/awesome-neovim/issues/2336
Originally assigned to: @rockerBOO, @Penaz91, @DrKJeff16 on GitHub.
Neovim Lua Development contains the following sorts of things:
saghen/blink.lib,nvim-lua/plenary.nvim,kkharji/sqlite.lua)folke/lazydev.nvim,milisims/nvim-luaref)bfredl/nvim-luadev,nvim-mini/mini.nvim#mini.doc,nvim-mini/mini.nvim#mini.test)svermeulen/vimpeccable,OXY2DEV/helpview.nvim)So it needless to say that the category is quite bloated, which isn't so suprising considering how ambiguous the name is (is this for Lua development in Neovim? Lua development for Neovim? If for, are libraries included? and so on).
Fennel is kinda similar and is less bloated only due to Fennel being less popular. Here is what it contains:
udayvir-singh/hibiscus.nvim)aileot/nvim-thyme,Olical/nfnl,rktjmp/hotpot.nvim)Olical/conjure)I propose the following:
[Lua]and[Fnl]?)Problems not covered:
Obviously open for discussion :3
@sukineco commented on GitHub (May 29, 2026):
Okay, some addtions.
On the second thought,
udayvir-singh/hibiscus.nvimis not quite a Library? Or is it? It's a library for writing init file, not plugins.I saw Integration category being mentioned before (here) and I think it would be a suitable solution for Fennel integrations. UPD: If Integration passes, it could help with unnesting Split and Window via moving out Tmux which allows for further merging with UI; Terminal Integration and Git might also belong here (Git may require splitting Github and Gitlab into their own subsections of Integration which seems fine to me).
Plugins for Neovim Lua development are kinda Programming Languages Support/Lua? Awesome Emcas does the same thing with ELisp but it's obviously a different case. Maybe some Programming Languages Support/Lua/Neovim would fit? UPD: I saw talks about nesting in #1875, parsing point makes absolute sense so maybe additional nesting is a bad idea.
Off-topic. Programming Languages Support should have a separate subcategory for every language. It'd be just more organised and so is easier to navigate through.
Off-topic. Dependency Management has a rather confusing name and all plugins from there could easily be merged into Programming Languages Support.
@sukineco commented on GitHub (May 29, 2026):
Also a huge off-topic on colorschemes. If Library passes, Colorscheme Creation could be merged into there which in perspective allows for merging Colorscheme into UI (as proposed in #1875) without additional nesting.
@sukineco commented on GitHub (May 29, 2026):
Summary
nvim-lua/plenary.nvimlooks reasonable@DrKJeff16 commented on GitHub (May 29, 2026):
At first value, I feel that a "Library" section is a bit wonky. Some of these plugins to be moved there can be utilized on their own as a standalone plugin.
Will have to think this through later today when I'm free.
A good idea could be a draft PR, like #2311, to have a good idea how things would be ordered.
@sukineco commented on GitHub (May 30, 2026):
Well, I think "Library" could be just a fallback for library-like plugins if there is no better place for them. Anways it's better than bloating "Utility" even more or placing these plugins in some seemingly unrelated categories.
@DrKJeff16 commented on GitHub (May 31, 2026):
Need @Penaz91's opinion.
@Penaz91 commented on GitHub (May 31, 2026):
The "Neovim Lua Development" section has been left a bit to its own devices since I first saw the project (way before I joined the maintenance team).
I think the main objective there is to gather plugins that help "Programming Neovim using Lua" (and not the opposite). In essence all the plugins that:
I think the "Fennel" section was meant to be under "Neovim Lua Development", since Fennel can call Lua functions, but don't quote me on that.
In general:
vim.api.nvim_set_keymapAPI) or to use other lua-compatible languages for their config.This should cover most cases that I see happening right now. The only thing that may be a bit wonky is the definition of Library, in case someone is not agreeing with mine (aka "everything that shouldn't be written twice, see
plenary.nvim).I'm available for any question in regard to this matter, I may not respond quickly but I'll try to be as comprehensive as possible when I do.
@sukineco commented on GitHub (May 31, 2026):
Yeah, I kinda fully agree with this but I think it's better for "Neovim configuration helpers" to be a subsection. Maybe something like this would work?
Also I think instead of "Fennel" it could be "Third-party Languages Support" or something like this because we already have
gpanders/nvim-moonwalk(in "Utility" rn) at very least.And, kinda off-topic tho, if this kind of structure is fine then here is no place for "Integration"; should I open a separate PR for it? For me at least, "Integration" seems like a good thing.
@Penaz91 commented on GitHub (May 31, 2026):
This sounds like a good starting point.
Configuration is a way of coding the editor in an of itself so there is some overlap and I can see why you'd want to make a subsection out of it.
If there will be a "third party languages support" we risk having all languages mixed up (and making more subsections might break sites that use this repository as their data source)
Depends on what "integration" will contain and what you mean for such term. Breaking down the problem in smaller chunks is a good idea though, so I would say to hold off on that for now and tackle it in another PR.
@sukineco commented on GitHub (May 31, 2026):
Mostly for clarity but maybe placing such plugins just in "Extending Neovim" would be fine.
Adding a separate section for every language then? Also, would "Fennel & Lisp" be a better fit then (I'm just developing a lisp language specifically for Neovim and still not quite sure where to place it because it's not Fennel but spiritually is very similar).
When I placed Fennel there it was just a bad idea it seems. I think of "Integration" as the "Programming Languages Support" but for external tools (git, github, ai agents, tmux and so on); not quite sure if "Terminal Integration" should be subsection in this case.