Open koshell opened 1 month ago
I know nothing about NeoVim (I use VSCode) but I believe that the function type definition of vim.uv.fs_stat
comes from here: https://github.com/LuaCATS/luv/blob/main/library/uv.lua#L646-L658
--- Equivalent to `lstat(2)`.
---
--- **Returns (sync version):** `table` or `fail` (see `uv.fs_stat`)
---
--- **Returns (async version):** `uv_fs_t userdata`
---
---@param path integer
---@return uv.fs_stat.result|nil stat
---@return uv.error.message|nil err
---@return uv.error.name|nil err_name
---
---@overload fun(path:integer, callback:uv.fs_lstat.callback):uv.uv_fs_t
function uv.fs_lstat(path) end
It returns the type uv.fs_stat.result|nil
as 1st param which is defined as a class
here: https://github.com/LuaCATS/luv/blob/main/library/types.lua#L78-L96
---@class uv.fs_stat.result
---
---@field dev integer
---@field mode integer
---@field nlink integer
---@field uid integer
---@field gid integer
---@field rdev integer
---@field ino integer
---@field size integer
---@field blksize integer
---@field blocks integer
---@field flags integer
---@field gen integer
---@field atime uv.fs_stat.result.time
---@field mtime uv.fs_stat.result.time
---@field ctime uv.fs_stat.result.time
---@field birthtime uv.fs_stat.result.time
---@field type string
AFAIK LuaLS will not expand class
definition in hint / hover, it will only expand alias
(when hover.expandAlias = true
). And I cannot reproduce your case that the uv.fs_stat.result
class get fully expanded π
I tested with the following in a new workspace:
.luarc.json
{
"workspace.library": [
"${3rd}/luv/library"
],
"hint.setType": true,
"hint.enable": true,
"hover.expandAlias": true
}
---@type uv
local uv
local response, , = uv.fs_stat("")
- result
![image](https://github.com/user-attachments/assets/9fe9ae22-223b-47f9-80c8-f7947a5d33ab)
I don't know if this issue is NeoVim specific? Maybe somehow in neovim, the `class` will still get expanded? π
In VSCode, the length of inlayhints is limited by default, so I suggest you ask Neovim to implement this feature.
I know nothing about NeoVim (I use VSCode) but I believe that the function type definition of
vim.uv.fs_stat
comes from here: https://github.com/LuaCATS/luv/blob/main/library/uv.lua#L646-L658--- Equivalent to `lstat(2)`. --- --- **Returns (sync version):** `table` or `fail` (see `uv.fs_stat`) --- --- **Returns (async version):** `uv_fs_t userdata` --- ---@param path integer ---@return uv.fs_stat.result|nil stat ---@return uv.error.message|nil err ---@return uv.error.name|nil err_name --- ---@overload fun(path:integer, callback:uv.fs_lstat.callback):uv.uv_fs_t function uv.fs_lstat(path) end
It returns the type
uv.fs_stat.result|nil
as 1st param which is defined as aclass
here: https://github.com/LuaCATS/luv/blob/main/library/types.lua#L78-L96---@class uv.fs_stat.result --- ---@field dev integer ---@field mode integer ---@field nlink integer ---@field uid integer ---@field gid integer ---@field rdev integer ---@field ino integer ---@field size integer ---@field blksize integer ---@field blocks integer ---@field flags integer ---@field gen integer ---@field atime uv.fs_stat.result.time ---@field mtime uv.fs_stat.result.time ---@field ctime uv.fs_stat.result.time ---@field birthtime uv.fs_stat.result.time ---@field type string
AFAIK LuaLS will not expand
class
definition in hint / hover, it will only expandalias
(whenhover.expandAlias = true
). And I cannot reproduce your case that theuv.fs_stat.result
class get fully expanded π I tested with the following in a new workspace:* `.luarc.json`
{ "workspace.library": [ "${3rd}/luv/library" ], "hint.setType": true, "hint.enable": true, "hover.expandAlias": true }
* test.lua
---@type uv local uv local response, _, _ = uv.fs_stat("")
* result ![image](https://private-user-images.githubusercontent.com/16996876/355283526-9fe9ae22-223b-47f9-80c8-f7947a5d33ab.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjI5Mjg1NjksIm5iZiI6MTcyMjkyODI2OSwicGF0aCI6Ii8xNjk5Njg3Ni8zNTUyODM1MjYtOWZlOWFlMjItMjIzYi00N2Y5LTgwYzgtZjc5NDdhNWQzM2FiLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA4MDYlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwODA2VDA3MTEwOVomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTRlY2QyZGFmMDQ1OWQ2ODlkZjk2ZjY1ZDIxYzU1ZGEzNTExMGEyODM5Y2YwYmRmZmUwMzQxOGZmOWIwOGM2YzMmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.K_loTXak0miF0FgdfGI4UJZhiXNd_FpNcBdZAIfBn24)
I don't know if this issue is NeoVim specific? Maybe somehow in neovim, the
class
will still get expanded? π
This sent me down a rabbit hole. I was using the luvit-meta definitions as one of the plugins I use recommended it for uv types. And would't you know it, a huge alias.
That solves that mystery, I'll probably swap annotation sources for now and I'll see if I can raise the idea with the Neovim team.
How are you using the lua-language-server?
NeoVim
Which OS are you using?
Windows WSL
What is the issue affecting?
Other
Expected Behaviour
Ideally if the hint is over a certain length it would be trimmed to fit within that length.
Actual Behaviour
Currently there does appear to be some trimming of the hint if it is exceedingly long but it appears that it is very generous with what 'too long' is. In my case I would want it to be far more conservative, but I understand not everyone would have the same preference so a config value would be nice. I'll insert some examples below.
Reproduction steps
First make a really long type (a lot of '@cast' annotations will get you there quickly). Then enable inlay hints and watch as whole lines get filled with the inlay hint.
Additional Notes
Here is an excerpt from my Neovim configuration to demonstrate who bad it can get, I've wrapped the hints in comments to make reading easier:
As you can see, the verbosity of the type for
response
makes the hint basically useless. There doesn't appear to be any faculty for controlling hint length in the lsp client capabilities or Neovim's lsp client so I'm hoping to be able to configure the server to just not send such long inlay hints in the first place.I got carried away thinking about how limited hints could be displayed. Feel free to ignore everything past this point.
As for what to send instead, in my opinion I see three options:
response
hint, something like this: { gen: integer, flags: integer, atime: { nsec: integer, sec: integer }, ... } | nil
. However this could be complex if it isn't simple to calculate a point to cut.: { gen: integer, flags: integer, atime: table, ctime: table, birthtime: table, uid: integer } | nil
. This could be combined with 2 to handle very large flat types (a table literal with dozens of keys).If possible it would prioritise the type information for the top most values, then prioritise the types in the order their defined. The chances of a developer wanting to know the type of a table nested three layers deep is going to rare in comparison to a developer wanting to know the type of the second value in a table. Ideally that would mean:
{key: value, ...}
and potentially shortening it to justtable
if the key/value is particularly long.Ultimately your not guaranteed to be able to shorten any arbitrary type like this, but it would go a long way for long literal types. Only a subset of literals would need to support abbreviation, these are them (in my opinion):
{ key: value, ... }
type | type | ...
[type, type, ...]
Log File
No response