update

[xuhuanzy]

No description provided.

[lewis6991]

I don't understand what this does? I thought completion already works without this.

[xuhuanzy]

This is to enable automatic import of subfields. We can't directly provide import suggestions for subfields of all exported tables, as this would severely pollute the auto-completion hints in a huge project and lead to very poor performance. This is especially true in game projects where Lua is widely used, as they often have a large number of configuration tables that could cause auto-import to freeze.

Here is an example:

-- test1.lua
---@export
local export = {}
export.func = function()
end

func -- When you type 'func', the auto-completion will suggest whether you want to automatically import 'test1.func'.

[xuhuanzy]

Another benefit of this approach is that when an export table is marked with ---@export, we can provide diagnostics for undefined fields.

Additionally, we might later provide a diagnostic for disallowed imports, as ---@export can accept a variable. For example, when it's specified as ---@export namespace, it will only allow imports of that file from the same namespace.

[lewis6991]

If I understand correctly I think I use @class on an exported table for a similar effect: to get undefined field diagnostics.

Does using @export have any other benefits over @class

Additionally, we might later provide a diagnostic for disallowed imports, as ---@export can accept a variable. For example, when it's specified as ---@export namespace, it will only allow imports of that file from the same namespace.

Sorry I don't understand what this means. By import do you mean require?

[xuhuanzy]

@class does not provide automatic import of subfields, and these two are not conflicting. @class can also include @export.

@export simply tells the LSP how to handle the export of this variable.

[xuhuanzy]

@namespace is a namespace. After using @namespace in a file, all subsequent type definitions will automatically have the prefix declared by @namespace added. It also implies @using.

@using is for referencing a namespace and does not affect type definitions.

As for @export, its current primary purpose is to assist with completion, but in the future, we will implement a simple file visibility control for it.

[xuhuanzy]

---@export is globally visible by default.
---@export namespace is only visible within the current namespace.
---@export global is globally visible.

[xuhuanzy]

Now, a simple module import visibility control has been added for him. When importing variables marked with @export, if it is ---@export namespace, it will check whether the current file's namespace matches it. If not, a warning will be issued.

[xuhuanzy]

Sorry I don't understand what this means. By import do you mean require?

yes

[xuhuanzy]

If @export is not marked, everything remains the same as before. @export is only meant to enhance the module import experience and slightly restrict the current situation where imports can be used freely.

[xuhuanzy]

Feature: Index members allow defining an alias, which will be used as the display during completion.

If a comment starts with [xxx], it is considered to add an alias for completion to the index, and whitespace characters are allowed before and after the content inside the [].

---@class Point
---@field [1] number # 	[ x ]
---@field [2] number # [y]
---@field [3] number # [z]
---@field [4] number # If there is any non-whitespace character before it, then it is not defining an alias. [error]


local test = {
    [1] = 1, -- [nameA]
}

[CppCXY]

@xuhuanzy since you are rolling all manner of updates into single large PRs, would you mind fixing the following small inconsistency while you're at it? reportsemmylua_check

[duplicate-require] Advice:
<diagnostic>
Hints: 1

The should be reported as for consistency (and same for other "Advices").[duplicate-require]``Hint:

I remember it should be that the library I used didn't have hints.

[CppCXY]

Yeah, I looked for it and saw that you used ariadne for the output, which (weirdly) only contains Advice. Options:

1. open a feature request there (arguing that "Error, Warning, Info, Hint" are standard LSP types that should be supported out of the box);
2. use a custom kind for Hint (and Info?);
3. report as Advices: ... for consistency;
4. do nothing.

5. Perhaps we can also write one ourselves.

[xuhuanzy]

The [duplicate-require] should be reported as Hint: for consistency (and same for other "Advices").

I haven't used emmylua_check, it should be implemented by cppcxy.

[xuhuanzy]

feature: Index access now displays aliases in the hint.

Can be turned off via hint.index_hint

[xuhuanzy]

@lewis6991 @clason @CppCXY Is there a better character than using > as a prefix?

[clason]

Hmm, not sure I'd ever use that feature myself, but maybe just put the alias in parentheses?

point[1 (x)]

Or use a colon (to match the type annotation)?

point[1: x] or point[1 :x] (note the spaces; former looks nicer to me, but latter looks more like a "symbol" in other languages, which might be appropriate?)

You could also treat it like a "field name": point[x: 1] to have a uniform style (not sure it makes sense to distinguish index_hints from other hints)?

[lewis6991]

: seems better than > to me.

[xuhuanzy]

You could also treat it like a "field name": point[x: 1] to have a uniform style (not sure it makes sense to distinguish index_hints from other hints)?

This is a key name, not a type. I didn't use a colon (:) as I think it could be confusing.

[clason]

Then :x is my suggestion. I think the consistency with other hints is useful, and the different order makes enough of a difference.

[CppCXY]

Yeah, I looked for it and saw that you used ariadne for the output, which (weirdly) only contains Advice. Options:

1. open a feature request there (arguing that "Error, Warning, Info, Hint" are standard LSP types that should be supported out of the box);
2. use a custom kind for Hint (and Info?);
3. report as Advices: ... for consistency;
4. do nothing.

I have refactor the emmylua_check, you can try the new version. I have removed the ariadne.

[CppCXY]

Nice, and seems faster, too! Minor suggestion: Use underlines (or -----) instead of carets? Or with the color highlighting, the additional marking is redundant? (Although may be better for accessibility to have both.)

I have removed the carets, but some unicode issue need resovle

[CppCXY]

Nice, and seems faster, too! Minor suggestion: Use underlines (or -----) instead of carets? Or with the color highlighting, the additional marking is redundant? (Although may be better for accessibility to have both.)

I have fixed the unicode issues , and it should basically work now.