Update mini.doc to LuaCATS
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 42/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- lua
- Domain
- documentation
Research direction
Start with the mini.doc module and read the linked LuaCATS documentation, especially the @param format and the LuaLS compatibility note. Compare that specification with the current EmmyLua-like annotation behavior described in the mini.doc help section. Done means mini.doc follows the documented LuaCATS structure and supports user-defined types without relying on heuristic type searches.
Written by the indexing model from the issue text.
Description
Contributing guidelines
- I have read CONTRIBUTING.md
- I have read CODE_OF_CONDUCT.md
Module(s)
mini.doc
Description
LuaLS/lua-language-server is the most used implementation Language server for Lua. One of its features are annotations implemented as LuaCATS (Lua Comment And Type System). As stated in their docs:
LuaCATS annotations are no longer cross-compatible with EmmyLua annotations as of v3
The current implementation of mini.doc try to parse EmmyLua-like annotations. Compare to EmmyLua annoation, LuaCATS define a precise specification for annotation.
For instance, the mini.doc :help section mentions:
Hooks for sections which supposed to have "type-like" data ('@field',
'@param', '@return', '@type') automatically enclose first found
"type-like" word and its neighbor characters in '(<type>)' (expect
false positives). Algorithm is far from being 100% correct ...
Conversely, the @param annotation supported by LuaLS/lua-language-server is explicitly defined as:
---@param <name[?]> <type[|type...]> [description]
In this format, the type directly follows the parameter name, eliminating the need for heuristic searches for the type. Additionally, this format simplifies the integration of user-defined types into help.txt.
While I could develop my own hooks to adhere to the LuaCATS specification (skill permitting), I believe that aligning with a dominant and well-documented standard would be more advantageous for the community.
- Dominant language
- Lua
- Stars
- 9.6k
- Forks
- 314
- Avg merge
- 19h 10m
- Merged PRs (30d)
- 7
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from nvim-mini/mini.nvim
-
feature-request mini.icons
Difficulty 1/5 Under an hour Newbie friendliness 82/100
-
'mini.nvim' and multicursorMay be free again @justinmk claimed this 31 days ago, and no pull request is open. OpenALL neovim-upstream
Difficulty 5/5 Over a week Newbie friendliness 28/100
-
mini.statuscolumn
Difficulty 5/5 Over a week Newbie friendliness 25/100
-
feature-request mini.surround
Difficulty 3/5 1-2 days Newbie friendliness 52/100
-
new-module
Difficulty 5/5 Over a week Newbie friendliness 25/100
All issues in nvim-mini/mini.nvim
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
jitsi/jitsi-meet#18020 ·
Maintainers usually reply within 1 day
-
GTK4 apps (Nautilus) aren't blurred: GTK 4.24's ext-background-effect makes Hyprland 0.56 skip blurOpen
Difficulty 1/5 Under an hour Newbie friendliness 94/100
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
windwp/nvim-ts-autotag#266 ·