the tests are failing now, because it's generating completions
differently, with no documentation or completion types, but it seems
like its working well.
Fennel doesn't yet support column numbers in its warnings, but I'm going
to attempt to add them in 1.5.4+. This code will take advantage of those
numbers if/when that happens.
This fixes an issue where a parameter name that is a substring of the
function name causes the client to highlight the function name substring
instead of the argument. Using ranges of the signature string avoids the
problem.
Operator with no arguments check failed when the first argument to the
operator was falsy. We might want to have a new lint to check for
"always false/true" expressions but this report was incorrect and the
quickfix replaced incorrect code.
The spec says diagnostic.codeDescription should be an object with an URI
linking to information about the error, we were using it as a string
identifier for the diagnostic.
This was making Helix ignore all diagnostics from fennel-ls.
Changed diagnostic.code to be the string identifier, removed numeric
identifiers and codeDescription field.
The unnecessary tset lint was assuming a single key, but it was
triggering for calls with multiple nested keys, causing the quickfix
action to drop all elements after the fourth argument, which was assumed
to be the value.
Now it's been updated to handle nested calls of any depth.
Function signatures rendered from ast were being rendered differently
from signatures rendered from metadata, this unifies them, using the
metadata format for both.
Before:
(fn func-name [arg1 arg2] ...)
After:
(func-name arg1 arg2)
This signature is used in the 'hover' feature and in completion
documentation.
This patch also adds three dashes as a separator between the signature
and the documentation text to improve readability. Since the text is
being interpreted as Markdown, this results in a line being drawn. This
format convention matches other language servers, for example LuaLS.
This implements the simple form of the signatureHelp feature, which only
displays the signature of the function being typed, without indication
of the active argument.
Active argument detection, while accounting for destructuring to support
each and for special forms turned out to be more involved than expected
and is left for a follow up patch.
These strings will be displayed in a menu for the user to select.
The error codes, in addition to not being human readable sentences,
describe the issue being reported, not the solution that will be
applied.
The code action response only includes the human readable string, so the
tests need to check for that. I considered adding a custom field but
decided against going out of spec.
