-
-
Notifications
You must be signed in to change notification settings - Fork 827
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Lua type annotations #3132
Comments
Hmm it says that the link was malformed... do you mind trying to ping me on matrix? (still @kylechui) |
I also support this. There are two projects I know of that add annotations (both by folke, actually)
While neodev uses annotations available in nvim's code, Emmylua takes a different approach and creates dummy files with empty functions and the the respective documentation added as luadoc above, for example in the file local M = {}
-- ...
-- Returns the filesystem path of the app.
--
-- Parameters:
-- * None
--
-- Returns:
-- * A string containing the filesystem path of the application or nil if the path could not be determined (e.g. if the application has terminated).
---@return string
function M:path() end
-- ...
return M All the annotations are saved in a folder. That folder only has to be added as a workspace library either in the configuration for the lua lsp, or in a The approach of EmmyLua.spoon is quite straightforward and should be possible for WezTerm as well. |
After trying to use https://github.com/nekowinston/wezterm-types ( @nekowinston ) , I realized I had to annotate the variables myself e.g. ---@type WezTermBlah
local wezterm = require "wezterm" But then I found @jason0x43 's https://github.com/jason0x43/dotfiles/tree/master/config/nvim/lua/user/types/wezterm which did not require me to annotate the vars myself. Here are the changes that were needed for using it with nvim/lua_ls after extracting that folder at
I see a mention of @wez saying on matrix that he can generate the types automatically from the source code. If so, supposedly this is the format that's most convenient acc. to this experiment. |
took them from here https://github.com/jason0x43/dotfiles/tree/master/config/nvim/lua/user/types/wezterm but renamed init.lua to wezterm.lua, so it works without nesting dir link above were in this issue: wez/wezterm#3132
Hmm, I tried various repos I could find for Due to the size and the ongoing pace of WezTerm development, I think auto-generating it from wezterm itself would be the way to go. |
TL;DR: have been looking at the same issue the last few weeks, and generating type annotations from the docs seems to be the easiest option for me too. I have been looking for a good way to create lua language server type annotations from rust code myself. I don't think there is a ready solution available at the moment. I actually started writing a rust implementation for the lua_ls type annotation system (only annotation/documentation generation) and proposed it as a solution in the yazi project here and here, but for now it looks like the discussion has stalled. Even if my attempt were successful, I am not convinced it would be a good solution unless there is either
|
I think there are two parts to this:
The former either needs some support from mlua, or needs to employ something like the Api Definition stuff in eg: dropshot. dropshot is a REST API helper, rather than lua, but the concept and model could be applied to lua. The idea is that a proc macro with declarative attributes could be used to annotate the various functions and collect them together in a supplemental metadata struct. There could then be a The latter could leverage the existing Lines 51 to 52 in b8f94c4
The same trait could be applied to more of the various types that are part of the API. |
- Not using luvit - wezterm type definitions are a mess (see also wez/wezterm#3132)
- Not using luvit - wezterm type definitions are a mess (see also wez/wezterm#3132)
is this being developed |
Is your feature request related to a problem? Please describe.
Seeing as Lua is a dynamically typed scripting language, it might be beneficial to include type annotations to provide autocomplete (to reduce typos), type-checking (to reduce other errors), and documentation in the editor itself.
Describe the solution you'd like
Have the keys for the configuration table be annotated, so users of Lua LSP can enjoy a better configuration experience.
Describe alternatives you've considered
The documentation on the website is very clear and helpful (in particular with having the default keys right there), but requires another window open to look back and forth between.
Additional context
Seeing as the codebase is written almost entirely in Rust, I'm not sure how the annotations would work (since they're typically added in Lua files). Here's some screenshots illustrating what could be possible:
The text was updated successfully, but these errors were encountered: