This is a case of "the ancestral laws must not be altered" (a historical legacy issue). The old version of emmylua had effectively ceased maintenance long ago (the original author stopped updating it), and these std definitions have long been outdated.

Although it's still called emmylua now, the core is entirely different. In fact, I'm quite puzzled as to why the project continues to bear the name emmylua.

I agree about the name, especially since this project supports LuaCATS and not EmmyLua

Because I was an member of EmmyLua and the early version of this project was implemented in C#, the name was inherited

Would it make sense to change the name?

which name? I want to keep the name 'emmylua' because 'luals' is already taken, and everyone is very accustomed to this name. Additionally, it is called 'analyzer' because it was originally copied from 'rust-analyzer'.

emmylua doesn't make sense since this project doesn't support EmmyLua.

Maybe lua_analyzer or luacats_ls?

emmylua doesn't make sense since this project doesn't support EmmyLua.

Maybe lua_analyzer or luacats_ls?

I can't update this website, so it remains as it is. I kept EmmyLua because it serves as the language server for VSCode EmmyLua. Additionally, I chose to be compatible with the current LuaCATS, but I didn't follow LuaLS 100%. In fact, most of LuaCATS was decided after discussions between Sumneko and me. Our plugins will choose to be syntactically compatible with each

In fact, the functionality of that plugin is quite primitive and includes some unnecessary features.
Additionally, there are now noticeable differences between the plugin and LuaCATS.

I can't update this website, so it remains as it is. I kept EmmyLua because it serves as the language server for VSCode EmmyLua.

That is confusing. There seems to be 3 different Lua annotation formats, but only two are documented, and this project doesn't support EmmyLua.

The good thing about LuaLS is that it defines LuaCATS as something separate to EmmyLua with documentation for the annotations. Will you do something similar for this project ("new emmylua")?

Without clear communication, adoption will be difficult.

The documentation will be provided later, but the foundational work is not yet complete, so providing it now is unnecessary.
Of course, it would be best if new maintainers could join in to help with the documentation.
I recommend using VitePress to build the documentation.

Basic markdown files within this project would be sufficient for the short term.