-
-
Notifications
You must be signed in to change notification settings - Fork 354
Diagnostics: allow disabling EmmyLua luadoc annotations #2391
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
Comments
Yes! I am using LDoc and was confused that this extension doesn't support it, but also that it seems to force something else that I don't use. I had assumed LDoc (for all its faults) was the currently preferred (only?) way to generate Lua documentation from code, and could also be used for code hinting. Is EmmyLua more common? Better? I'd not heard of it until now (which I'm sure is on me). |
So let me tell you a story, the author of emmylua didn't hear of LDoc when he developed emmylua, and lua didn't have a decent plugin or IDE at the time. Later, sumneko lua introduced emmylua doc as the basic type system, and extended it to become today's LuaCats doc. We don't develop lua plugins to fit the needs of the community, but to meet our own development needs, and emmylua doc is more in line with actual development needs than LDoc. I'm not urging you to change your doc format, but the odds are we won't provide support for LDoc. |
Nobody is asking to add support for LDoc. Just allow us to disable LuaCats entirely in files or projects where LDoc is used. |
Classic. 😆 I'd love LDoc support, but I'm not asking for it. Like the OP says, just an option to disable EmmyLua for people not using it would be nice. I'm not personally tied to anything. If EmmyLua can produce HTML documentation then I'd be happy to switch. Is that possible? |
@Mark-LaCroix Yeah, it's not the first time I see on github how maintainers misread OP.
EmmyLua wasn't intended to generate docs AFAIK. That's the half of the problem though. |
LuaCats doc support is not pluggable, it is the foundation of the whole plugin, all diagnostics and parsing are tied to it, so I think this is unlikely. |
That's FOSS for ya. I know from personal experience that it's hard to hear a request from a user and not assume that it's asking for more than it says. Beggars can't be choosers, and most users are beggars! It's a common and perfectly understandable misread.
Cool! It looks like it only supports Markdown and JSON, leaving the "last-mile" of providing functional UX to the user, and has no configuration options. Not anywhere close to a suitable LDoc competitor, but as has been said, that's not its goal.
I guess, but I'm not using it and the plugin still works great for me in all other ways. I don't need to "unplug" it, just hide it. In the pantheon of "won't fix" this one is odd. LDoc isn't necessarily the answer (ideally it's to build out the existing docs generation feature), but I find it hard to believe that the intent of maintainers is to force users to pick between code-hinting and proper docs generation. If someone where to propose a PR to address this in one way or another, would it be rejected on design grounds? |
My idea is to add an option: Only when the few characters at the beginning of the file are But I am busy with other things recently, and you are welcome to propose PR. |
The price of disabling it is to use it. |
I observe that LuaCats repo has widely adopted EmmyLua tags. Given that it's hardwired, is it possible to modify behavior of lua-lsp so as to suppress errors for a set of LDoc tags at low cost? There is quite short list of tags on their LDoc web site. The major problem I face with lua-lsp tags currently is the overhelming list of errors for non-compatible tags (.e.g
@Mark-LaCroix Well given that lua isn't a typed language LuaDocs are essential to a LSP implementation. Meaning that this may require a completely new language server implementation with tweakable tags... But if it can be done in a PR, well that would be nice. |
I've got a feeling this issue might be a xy problem. Is the motivation for disabling LuaCATS annotations to have a way to generate documentation (in some web-compatible format?) from source code? Why even use LuaLS in that case? What do you get from LuaLS if you disable its type annotation system? |
@C3pa Well there is no way to suppress errors arising from incomptible luadoc tags.
That's my point above. It might require re-implementation of the entire LSP. |
I am still not getting your point. What features of the LSP are left after its type annotation system is disabled (if the type system potentially could be disabled)? |
Feel free to reopen/ping this issue in case of PR or new LSP. Thanks. |
hi, not sure if I understand correctly, so now we have a way to disable the Or is there a doc tool to auto-generate docs from lua-language-server annotations? I also tried the LuaLs wiki - export docs, but the generated markdown docs are not good looking to me, not sure if there's a way to configure the style. |
The emmylua doc parser is the basis for sumneko lua, and cannot be disabled.
luals can generate the doc in json format, and then process it yourself |
got it, thanks for reply. |
I actually tried a lot of solution for auto-generate docs from luals annotations. there's a maintained sphinx-lua: https://github.com/boolangery/sphinx-lua. It supports the EmmyLua annotations, but even EmmyLua itself is not enough for LuaLs now. |
new issue please, as I said before, lua-language-server generates documents in json format, so you can build your own documents on top of that, and as far as I know there are no other third-party libraries that support parsing of luacats. |
How are you using the lua-language-server?
NeoVim
Which OS are you using?
Linux
What is the issue affecting?
Annotations
Expected Behaviour
Sorry for opening a "bug". This is actually a feature request. My proposal at #2369 was left unanswered.
I request to make it possible to disable emmylua specific luadoc annotations project-wide or file-wise (e.g. per file) entirely.
Motivation:
The text was updated successfully, but these errors were encountered: