Please add an option under the 'hint' category to specify a max length for hints

[koshell]

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:

    for _, path --[[ : string ]] in ipairs(--[[ t: ]] vim.api.nvim_list_runtime_paths()) do
      local lua_path --[[ : string]] = vim.fs.joinpath(path, "/lua")
      local response --[[ : { gen: integer, flags: integer, atime: { nsec: integer, sec: integer }, ctime: { nsec: integer, sec: integer }, birthtime: { nsec: integer, sec: integer }, uid: integer,
      gid: integ...(too long)...eger }|nil ]], _, _ = vim.uv.fs_stat(--[[ path: ]] lua_path)

      if (response or {}).type == "directory" then
        table.insert(paths, lua_path)
      end
    end

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:

1. Nothing at all. If the type is too long just don't send the hint at all. This could be confusing to some but I believe it's better then filling your line with useless information.
2. Hard trim the hint. In the case of the 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.
3. Simplify nested types. Using the response hint as an example again: : { 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:

1. Abbreviating the deepest table literal with {key: value, ...} and potentially shortening it to just table if the key/value is particularly long.
2. Starting at the deepest depth, abbreviate types in reverse definition order.
3. If no more types can be abbreviated at the current depth, go up a level and try again.

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):

• Table abbreviations would look like: { key: value, ... }
• Union abbreviations would look like type | type | ...
• Tuple abbreviations would look like [type, type, ...]

Log File

No response

[tomlau10]

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
}

• test.lua

---@type uv
local uv

local response, _, _ = uv.fs_stat("")

• result
  

I don't know if this issue is NeoVim specific? Maybe somehow in neovim, the class will still get expanded? 😕

[CppCXY]

In VSCode, the length of inlayhints is limited by default, so I suggest you ask Neovim to implement this feature.

[koshell]

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
}

* 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.