nvim_win_get_config returns lua-special-tbl when called from Lua

[altermo]

Problem

Some functions, like nvim_win_get_config, have a lua-special-tbl float in the returned values, but what the user sees when inspecting it is a table with the keys true and false set to some numbers, which is confusing.

Expected behavior

A solution is to add a notice to the documentation of the functions that may have lua-special-tbl in the return value about how the return value may contain lua-special-tbl.

An alternative solution would be to make it so that inspecting a lua-special-tbl would not return the table with boolean keys, but either a string similar to vim.empty_dict(), or the table with the keys being vim.type_idx and vim.val_idx instead of true and false

[justinmk]

add a notice to the documentation of the functions that may have lua-special-tbl in the return value about how the return value may contain lua-special-tbl

That is all functions that can return a dict.

make it so that inspecting a lua-special-tbl would not return the table with boolean keys, but either a string similar to vim.empty_dict(), or the table with the keys being vim.type_idx and vim.val_idx instead of true and false

Do you mean vim.inspect()?

[altermo]

For the documentation, what I thought of was for those functions that would, if not for vim-script compatibility reasons, return a normal number/table, but because of vim-script compatibility, return a lua-special-tbl (or returns a table that contains a lua-special-tbl).

For the inspection, mostly yes: I would also want to include tostring, but I don't know how feasible it is to set metatable.__tostring for lua-special-tbl.

[bfredl]

Some functions, like nvim_win_get_config, have a lua-special-tbl float in the returned values, but what the user sees when inspecting it is a table with the keys true and false set to some numbers, which is confusing.

Hmm in this particular case it is a bug. There is no "compat" going on here but vim.api.nvim_win_get_config() is a native API call. And as the type of row/col is an hard-coded Float, not a free Object, it should always be represented by a lua number (i e row=2 and row=2.0 is the same value already in the API layer)

Special dicts for numbers are only for cases where 2 as an int and 2.0 as a float are different as values, i e when representing foreign type systems.

[altermo]

The behavior of vim.api.nvim_win_get_config() returning lua-special-tbl being a bug was already brought up, and marked as intended behavior (#24430 (comment))

[bfredl]

That reasoning is incorrect tho, for the reasons I already mentioned. The type of a float position was intentionally chosen to be a number, not a foreign object of an unknown type. Neither is a "special case" of the other, it is just two different code paths which has always existed (and we fixed bugs like this multiple times in the past)

[zeertzjq]

Fixed by #27284