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

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

Issue ではファイルもテストも指定されていません。まず hint 設定と、inlay hints をフォーマットして送信するコードを見つけ、次に Neovim で長い @cast の例を再現してください。hint の下で設定可能な最大長が、短い hint に影響を与えずに長すぎる hint を制限し、選択した切り詰め動作が検証されていれば完了です。