Conversation
Decided to create a LuaLS annotation generator since the original one was only generating LuaCATS which is not compatible or used that much anymore. This should be a great improvement for those using the LuaLS LSP, very common amongst most IDEs and code editors :)
|
Hmmm yeah, the generated definitions look really similar to the cats ones, just with slightly different formatting. Some differences I noticed:
This is the definition syntax you're using right? https://luals.github.io/wiki/annotations/ It's the LuaLS definitions but it also says it's LuaCATS, so I'm confused. If they're the same thing, then this is just a different style of structuring the definitions, which is fine. But we should definitely pick one of the generators, or combine them somehow, instead of having 2 of them. |
|
Oh god, I also got confused. I had written a whole reply here, heck, I wrote a whole generator and tested it out myself on my own programs and the examples in the repository, all because apparently CATS was different from Sumneko's LuaLS annotation syntax, just to then realize that I was wrong about this, and that CATS and the LuaLS syntax seem to be one thing! I am afraid I wasted everyone's time here. We have two options now, fix up the existing CATS generator, or use my new one, though I see value on fixing what's already there instead of just rewriting the whole thing as I already did. I guess the problem all along was not that it was operating under a different syntax altogether but simply that the generator was not using all of the features or written for the new syntax |
|
Might get onto fixing the existing generator, right now. |
The type syntax actually does seem to be quite different, though... Most of the annotations show warnings and errors like these in LuaLS
|
|
Hm yeah, the |
Seems likely, lots of the stuff here seems like it was made for a different version of the same syntax, nowadays, a more "standarized" syntax is used, which is |
|
To be clear |
Is that necessary? We could just translate in the generator, instead of having to attach to a specific format, which I feel would be the best course of action simply because CATS isn't the only "target" the generators have |
|
Yeah, sorry that's what I meant. The cats generators will have to map |
|
Are there any decisions so far? I want to know whether it'd be preferred to update the existing generator or to replace it with the one i just made. I see positives to both outcomes, and I am willing to help iron out the kinks in the new generator, as well as just add the missing features to the original one. |
|
I don't have a strong preference, whatever's easiest and looks best in editors. I do like a few aspects of the old definitions
|
It is VERY cluttered, but I think it's okay that way, this is meant to be consumed mostly by the LSP, and it is still quite readable! Added both suggestions, plus the globals file. (I sincerely do not know why I didn't do it that way before!) Everything should work as expected, it essentially looks like this: 
The main drawback here though is that callbacks are extremely verbose, and must all be defined riiiight next to eachother due to some stupid limitation of how this thing handles the Something I am coming up with though, I think it would make sense to actually define the function types and the actual "fields" as separate things, so we can have the TYPE of the functions have the annotations, while the fields themselves are all tightly packed and put together |
oh my god what in the heck is this 😭 I dont think I could parse this |
Now it's not clumped anymore!
|
Actually, I have an idea for it, but I'll have to think about it proper |
|
We could probably restructure that one. Or it could just be table and documented in the notes. |
No need! I just implemented it in the latest commit, I think the syntax is good since it just has to make sense for the user. |
|
|
|
I think it is ready, I do not have any more meaningful changes to make, perhaps just code cleanups and optimization, but it does seem to work correctly for most of the cases in the Lövr API, I think feedback would be awesome to make this better, I'm open to any suggestions and/or changes. |
|
|
Could you use 2 space indentation and single quotes, to match the rest of the code in the repository? |
api/generators/luals.lua
Outdated
| -- Plus, they often have their own, separately mantained annotations instead. | ||
| if module.external then | ||
| print("SKIP") | ||
| goto continue |
There was a problem hiding this comment.
It would be nice to remain compatible with Lua 5.1 and Luau, which don't support goto.
| end | ||
|
|
||
| -- Assumes that an object with :sub, also has :__sub, for example | ||
| local function writeOperator(func, f) |
There was a problem hiding this comment.
Note that add/sub/mul/div methods are going away, might need another way to detect metamethods eventually.
There was a problem hiding this comment.
I think it would be awesome to simply define those metamethods as functions that start with __, and mark them as metamethods. or maybe have a special field within each object for metamethods specifically, which could help for the website UI to describe them as operator overloads
I believe CATS might be a better name, but just judging by how confused we both were by the naming scheme, I am not exactly sure. This generator does supersede the existing CATS generator, as it pretty much does the same thing but with an updated syntax which allows us to do more complex type checking, documentation, etc. |
Done, as well as change it to be compatible with Lua 5.1 and Luau. |
…for some of its values.
… code. Might revisit it eventually.
|
Ok sorry I finally got a chance to try this out. Here are the things I'd change:
Also, I think last time we were talking we decided to keep Happy to take care of any of this post-merge if you don't want to, just let me know |
2 participants
Decided to create a LuaLS annotation generator since the original one was only generating LuaCATS which is not compatible or used that much anymore.
This should be a great improvement for those using the LuaLS LSP, very common amongst most IDEs and code editors :)