`@param` fails to include multiline description

[rhys-vdw]

How are you using the lua-language-server?

Visual Studio Code Extension (sumneko.lua)

Which OS are you using?

Windows WSL

What is the issue affecting?

Annotations

Expected Behaviour

Attributes should be correctly parsed when they wrap over multiple lines.

Actual Behaviour

In VSCode:

---@param foo integer This is a long description that wrongs over multiple lines
---but is misinterpreted.
function x(foo) end

---@param foo integer
---
---Long description with multiple paragraphs, and a code example:
---
---Usage:
---```lua
---local result = x(5)
---```
function x(foo) end

Reproduction steps

Paste code above into VSCode.

Additional Notes

Surely it should be possible to write more than a single line of description for a parameter (and other tags).

Log File

No response

[CppCXY]

I suggest you can try emmylua.

[tomlau10]

seems duplicated as #2333, which the root cause seems to be @param currently doesn't support multiline description

[rhys-vdw]

seems duplicated as #2333, which the root cause seems to be @param currently doesn't support multiline description

That issue suggests that it does work in VSCode, and fails in NeoVim. Maybe this is a regression.

[tomlau10]

That issue suggests that it does work in VSCode

Not really.
In additionally notes of that issue, you can see that although the extra line is rendered, but the font style is different.
=> that means the line might be just appended as an extra line in the result markdown, instead of being part of the param description
=> @param doesn't support multiline description

---

---@param foo integer
---
---Long description with multiple paragraphs, and a code example:
---
---Usage:
---```lua
---local result = x(5)
---```
---@param bar integer desc for param bar<br>this is correct new line rendering
local function x(foo, bar) end

• if no description in the same line as @param => nothing about this param will be shown
• the middle part multi line description seems to be interpreted as function description, though the ordering is kept
  (rendered before the @param bar)
• when using <br> to do line break in param description, you can clearly see that font style of both lines matches,
  and it is different than the font style of the middle part

---

edit: found a workaround

okay so here might be a workaround: adding a dummy # in the first line 😂
=> such that the first line is not empty

---@param foo integer #
---
---Long description with multiple paragraphs, and a code example:
---
---Usage:
---```lua
---local result = x(5)
---```
---@param bar integer desc for param bar<br>this is correct new line rendering
local function x(foo, bar) end

edit2: opps... this renders fine when hovering the function, but not when hovering the param itself
=> still the mulitline part is not attached to the param itself

[MillhioreBT]

I suggest you can try emmylua.

EmmyLua seems very solid and I like it, but it lacks hundreds of features that LuaLS has. That's the only thing currently stopping me from switching and using only EmmyLua.

[CppCXY]

I suggest you can try emmylua.

EmmyLua seems very solid and I like it, but it lacks hundreds of features that LuaLS has. That's the only thing currently stopping me from switching and using only EmmyLua.

It supports all annotations of luals and includes even more advanced features. Apart from missing some diagnostics, it can share all third-party libraries and is extremely fast—I don't see what else it could be lacking.

[MillhioreBT]

It supports all annotations of luals and includes even more advanced features. Apart from missing some diagnostics, it can share all third-party libraries and is extremely fast—I don't see what else it could be lacking.

After your message, I took a few minutes of my life to check it again, and yes, it's still broken. It doesn't even work well.

Some things work, others don't. It's not consistent, and it can't be customized as well as with LuaLS.

The underlining it adds to variables is very annoying.
The type name for mandatory variables.
It can't find all the definitions, and even when it does, they don't work correctly.

Believe me, the speed of the EmmyLua plugin is noticeable, but it's also clear that it's not ready for production.
I would love to know Rust or any language that could be useful to support EmmyLua.
For a while now, I've been looking for something better than LuaLS since it's really slow at almost everything.
However, LuaLS is the best we have so far—it's very stable and reliable.

Note: This isn't hate, it just doesn't work for me personally. Maybe it's my computer? I don't know.

Examples:

[CppCXY]

After your message, I took a few minutes of my life to check it again, and yes, it's still broken. It doesn't even work well.

Some things work, others don't. It's not consistent, and it can't be customized as well as with LuaLS.

The underlining it adds to variables is very annoying. The type name for mandatory variables. It can't find all the definitions, and even when it does, they don't work correctly.

Believe me, the speed of the EmmyLua plugin is noticeable, but it's also clear that it's not ready for production. I would love to know Rust or any language that could be useful to support EmmyLua. For a while now, I've been looking for something better than LuaLS since it's really slow at almost everything. However, LuaLS is the best we have so far—it's very stable and reliable.

Migration indeed has some differences. Note that I have disabled return type extension fields unless they are tables. We adopt stricter standards and methods. If you wish to smooth out these differences, please raise these issues in my repository's issue tracker.

[CppCXY]

Examples:

Additionally, if a class needs to be called, it should be written with overload. I have disabled the default behavior of returning self.

---@class Event
---@overload fun(): Event
---@field onInspectItem fun(player: Player): void
Event = {}

local event = Event()

function event.onInspectItem(player)
end