Feature Request: Environment Scoping

[SlashScreen]

This is perhaps a niche use case, but some applications have different APIs available in different contexts (this set in a menu, this set in-game, this set in plugins, etc.). While arguably not a great design decision, is often unable to be changed because of legacy. What would be great is a way to scope members by these environments for the docs generator and the LS.

Usage:

To scope a member, you can give it an @env x... directive. For example, this function would be in the x and y environments.

--- @env x y
function foo()
  bar()
end

To restrict a file to a certain environment, place the directive at the beginning of the file:

-- x.lua
--- @env x

Then, foo is available here, since it's in env x.

Members unlabelled with an environment would belong to a "default" environment which is accessible from all environments. Unlabelled files would only have the default env available.

Generation

Each environment, including the default one, would get a generated doc_x.json . If there's only a default, there's only a doc.json.

Hopefully this isn't too hard to implement, as it's mostly just set theory manipulation.

[CppCXY]

I implemented a similar mechanism for xmake_ls, where all non-local variable definitions are treated as environment definitions. Variables in different files can only be accessed after include the target file using the include function. However, I do not intend to implement such logic for standard Lua. However, I think such logic is too hooker-like for standard lua

[SlashScreen]

However, I think such logic is too hooker-like for standard lua

What, uh, do you mean by this? I believe this is a mistranslation. If you do not want this for standard lua, is there a way we can toggle/emulate this behavior ourselves on a per-file basis?

…

Message ID: ***@***.***>

[xuhuanzy]

That would significantly increase the complexity, and for standard Lua, it's completely unnecessary.

However, we might implement a similar mechanism in Lua 5.5, though very likely not in the form of annotations.