I'm using the Helix Editor and when I put my cursor inside a string, and request the help signature it throws an error that -1 is an invalid value for u32. (helix is written in Rust)
This means these functions should never return a value below 0.
My change sets the activeParameter/activeSignature to null if the value is not greater-equals 0, which omits the activeSignature/activeParameter value in the response, as the spec allows, which helix happily accepts. (Helix sets them to the default value of 0 if the values are null or omitted see here and here)
(I've never written any Kotlin code, so feel free to recommend other ways to implement this)
Alternatives
With my change it is up to the client to choose the signature and parameter, and as the spec mentions, [...] In future version of the protocol, this property might become mandatory to better express this., this change may not be valid in future versions. The alternative would be to return 0 for both functions, if they don't return a value greater-equals than 0.
I'm using the Helix Editor and when I put my cursor inside a string, and request the help signature it throws an error that
-1
is an invalid value for u32. (helix is written in Rust)I took a look at the Language Server Protocol Spec and saw that the
activeSignature
andactiveParameter
are unsigned Integers according to the spec, so the implementation in helix seems to be correct.This means these functions should never return a value below 0.
My change sets the activeParameter/activeSignature to
null
if the value is not greater-equals 0, which omits the activeSignature/activeParameter value in the response, as the spec allows, which helix happily accepts. (Helix sets them to the default value of0
if the values are null or omitted see here and here)(I've never written any Kotlin code, so feel free to recommend other ways to implement this)
Alternatives
With my change it is up to the client to choose the signature and parameter, and as the spec mentions,
[...] In future version of the protocol, this property might become mandatory to better express this.
, this change may not be valid in future versions. The alternative would be to return 0 for both functions, if they don't return a value greater-equals than 0.