Possible improvements to analyzer

[notpeter]

I gave the new EmmyLuaAnalyzer a whirl and here's some things I found:

Bugs

• [x] Hover state does not show class fields

  

• [ ] "Read more" arrow always shows, even with subwindow is empty

  

• [x] ---@deprecated does not appear in hover. Calls to deprecated methods should be ~striken()~.

  

• [ ] Clicking EmmyLua in status bar results in "emmy.stopServer not found" error message.

  

• [x] Putting an invalid path (e.g. "fakedir" into workspace.library in emmyrc.json caused crash on startup. If you change/add this mid-session EmmyLua becomes non-responsive (and stop is broken).

  

• [x] #12

  

• [ ] Completions for ---@ should should only be type annotation related [@class,@param,@return,etc] <img width="684" alt="Screenshot 2024-05-02 at 21 17 58" src="https://github.com/CppCXY/EmmyLuaAnalyzer/assets/145113/19729092-f7df-4aea-86e6-09f8901add06">

• [x] #13

  

• [ ] Duplicate functions (with different params) inside a ---@meta are not suggested as multiple options (first wins?)

  

• [ ] Types on ... are not properly checked and ...? is displayed as... in function signatures.

  

• [x] Class field descriptions do not appear as part of extended suggestion, but are present in the hover window.

  

• [x] #14

  

• [ ] Assignments to optional returns (e.g. string? or string|nil do not preserve their nullability in types. This should be _File? or _File?.

  

• [x] workspace.library in .emmyrc.json only works with relative paths. 0.6.15 changelog here says:

  Now all places where paths can be filled support relative paths, absolute paths, and ${workspaceFolder} to represent the workspace, ~ to represent the user directory Tildes do not expanded properly (~/proj becomes /proj). Absolute paths are wrongly concatenated as paths under workspaceFolder. ${workspaceFolder}/../whatever works as designed.

• [ ] Assignments should preserve transitive comment annotations.

  

• [x] Quote handling for @alias types is not right (duplicated double quotes): "". Dunno if the EmmyLua types need to updated. Here is how LuaLS defines them for reference.

  

Settings

• [x] Please increase the default for workspace.preloadFileSize. Maybe 5120000?

• [x] .emmyrc.json: It'd be sweet to have a JSON schema. Then if you set "$schema" to the url users get config validation for free in VSCode. Are you intending to support .laurc.json as well? You're close enough to the LuaLS .luarc.json schema that I think you could implement proper superset of what it supports.

• [ ] .emmyrc.json: Please add support for runtime.nonstandardSymbol. Here's what I use for Playdate Development: ["+=", "-=", "*=", "/=", "//=", "%=", "<<=", ">>=", "&=", "|=", "^="]

Future suggested capabilities

• [x] Add colors/tokenize type/names inside comment annotations. fun(), | and : get fancy colorization, but everything else is just a comment (green).

  

• [ ] Analyzer should warn on duplicate assignments (unless inside ---@meta file)

  

• [ ] Analyzer should warn when assigning incorrect types.

  

• [ ] Analyzer should warn/error when nullable types are not checked for nil before calling. E.g. err:len() should have warning.

  

• [ ] Analyzer should warn when assigning to constants (this will fail at runtime)

  

---

Steps to reproduce:

1. Create a folder with an .emmyrc.json:

   {
   "workspace": {
       "preloadFileSize": 5120000,
       "library": [
           "../playdate-luacats"
       ]
   }
   }

2. Checkout https://github.com/notpeter/playdate-luacats/
3. Profit?

[CppCXY]

good work, but there are some things that are not as you said. Emmylua does not define syntax highlighting, but instead uses the default highlighting of VScode, which is maintained by Sumneko. The reason you didn't see it is because it was overwritten by your other plugins

[notpeter]

Good work yourself! It's impressive to see this coming together. Sorry to do such a big dump all at once. I totally understand if some of these are by-design or out-of-scope, but I just wanted to share initial feedback of what I saw using the new LS for a couple hours.

All the screenshots only have the EmmyLua and EmmyLuaCodeStyle extensions installed (I uninstalled Sumneko), but I had wrongly assumed that EmmyLuaVscode and EmmyLuaAnylzer were providing syntax highlighting and grammar definitions (via DocumentSemanticTokensProvider or your own Grammar) but you are correct, this is just the default TextMate syntax highlighting, currently maintained by Sumneko.

Took me a minute to find it, but the main VSCode repo has vscode/extensions/lua which points to the LuaLS/lua.tmbundle repo that I didn't know existed. Thanks for pointing me in the direction of this. I'll see if I can take a crack at a PR there which does some basic syntax highlighting of annotations (/me casually dusts off oniguruma regex syntax manual)

Otherwise, enjoy your holiday. Excellent stuff.

[CppCXY]

By default, the highlighting in VSCode is like this, I don't know why it's not rendered on your computer:

You've asked many questions, and it's hard for me to respond to each one individually. I've turned some tasks into issues and responded within them. For other task questions, I'll give a general response:

1. Type checking is not currently implemented because type inference is not yet perfect. Also, many linters take time to develop (sumneko lua has been accumulating for several years, and many people submit PRs, I'm basically doing it alone, so it will be slower in terms of time).
2. The alias issue is how emmylua supported it in the past, but I've tried to be as compatible as possible with both syntaxes.
3. Regarding the compatibility with .luarc.json, I initially planned to directly use .luarc.json, but I found that many configurations are meaningless to my language service. So, I adopted a form that is basically consistent with it, but to avoid confusion, I didn't directly use .luarc.json, but used .emmyrc.json instead.

[notpeter]

Sounds great! I understand if there's certainly a difference in feature set vs LuaLS, but I'm very excited for there to be multiple players in the Lua Language Server space. Your .NET code is definitely more accessible than LuaLS's mix of Lua and C++ spread across nearly a dozen repos. I'm going to go ahead and close this issue, I created it mostly to document my first couple hours evaluating it and I thought you would appreciate the feedback.

Excited to see how things progress. In particular, hopefully you can get cross platform builds that don't require the CLR going as that will certainly ease adoption. I think this is part of the success of LuaLS -- it does not need to depend / interop with your target lua environment, everything is batteries-included when you add the extension.

Anyways, impressive work and I hope the feedback was useful.

[CppCXY]

Because it uses a lot of reflection libraries, it's currently not AOT-compilable. dotnet projects can be compiled in a self-contained manner, but the result of the compilation is to package the entire dotnet runtime, which will cause the package size to increase significantly, roughly from 6mb to 70mb. This is also not conducive to distribution. Initially, this project was written in Rust, and used a lot of libraries and ideas from rust-analyzer. However, at that time, Rust's debugging tools were too poor. After a few years, I see that C# has become very popular now, and various debugging tools are very complete. So I rewrote the project in C#.

[notpeter]

Gotcha. 70mb is a little chunky, but I don't think it's out of line. Looking at my language servers:

Server	Size
lua-language-server	21MB
yaml-language-server	29MB
pyright	29MB
gopls	31MB
typescript-language-server	35MB
rust-analyzer	39MB
vscode-css-language-server	94MB
vscode-eslint	108MB

I'm not super familiar with the modern .NET ecosystem, but if it's possible (even if it includes the whole runtime) I'd suggest building a fat executable. Developers on MacOS/Linux are unlikely to have a prexisting runtime installed and it's not immediately clear that what is needed is the runtime (scroll down and look in the right-hand column, 72MB) and not the SDK (front and center, 600MB) so bundling 70MB is not only convenient, it may be more space efficient in the end.

You could support an alternate install methods (e.g. homebrew formula, chocolatey, etc) that automatically install the CLR as dependency but if you're targeting the widest possible audience I wouldn't worry about another 70MB.