Add options to trim leading dollar ($) sign.

[andradei]

I use fish-lsp with neovim and the blink completion plugin.
When I type $ start typing the variable name, blink will suggest the var name.
When I select it, I end up with $$<var name>.

Describe the solution you'd like
This discussion related to PHP shows a PHP LSP has the option to remove the leading $ dollar sign from the suggestion.

Something like set -gx fish_lsp_trim_leading_dollar along with equivalent command-line option would be great.

Describe alternatives you've considered
I tried checking blink configurations but there are none.

[ndonfris]

Thanks for the detailed report! This is indeed caused by fish-lsp not detecting that the $ prefix is already present when inserting variable completions. I'll try to include a patch for this in the next release, hopefully within the next week or two. I'm currently prioritizing semantic token support for the language server and expect to wrap that up within this timeline, but I'll update this issue if there are any delays. This issue doesn't appear to be blink specific for me so we probably can just assume that the eventual fix is the default expected behavior in all clients.

I believe the underlying issue is caused by fish shell's complete --do-complete returning variable names with the $ prefix intact, which then gets inserted alongside the user's already-typed $.

Notice how completions for $ queries include the $ in their results

The completion handler is legacy code—written in the project's early days and on the refactor roadmap for 4–5 releases now. A complete rewrite of the completion handler in the server would be the ideal solution, as the legacy code has accumulated technical debt and maintainability issues over time.

If you're interested helping with the completion handler rewrite, I'd be happy to assist:) Otherwise, we can visit this again at a later date, and work on a quick patch in the meantime.

My initial investigation led me to believe that the immediate fix would involve editing the CompletionItem.textEdit property, created by the FishCompletionData object in CompletionPager.complete to insert variable completions that include the $ prefix to the prior $ character position. Or alternatively, CompletionItem.insertText could be causing this.

Will make sure to update any future findings I come across when I get a chance to test this further, but here is my initial notes:

Technical details:

• Reproduction: echo $PA + trigger completion

  • assumes the $PATH variable exists and is not locally defined in the test document
  • ❌ current: echo $$PATH
  • ✔ expected: echo $PATH

• LSP properties involved: need to locate which CompletionItem property causes incorrect replacement:

  • CompletionItem.textEdit (takes precedence, shape: { range: Range, newText: string })

    • potentail issue: Intuitively, I assume this location would be the culprit, since it defines the exact range to replace in the document. However, from my testing, it seems like the textEdit.range might already include the range of the previously seen $ token in the current word range of the document.
    • Alternatively but more error-prone CompletionItem.textEdit.newText could remove $ characters when the completion request already starts with $.

  • CompletionItem.insertText (defaults to label)

    • potential issue: Lines 83 & 90 in pager.ts unconditionally add $ prefix via insertText = '$' + variable.name
    • insertText property is less flexible than the textEdit solution since clients might consider a request: echo $PA + trigger completion, as the user requesting echo $PA$PATH. However, I am uncertain ATM.

• Scope: Only child_process fish shell completions affected, not DocumentSymbol/FishSymbol/WorkspaceSymbol definitions parsed out of the current documents.

Noteworthy Features that a rewrite should support:

• Shell invocation is in getSubshellStdoutCompletions()
• Must handle empty completion requests with sensible default items
• Document cases where variable completions should preserve the leading $ vs where it shouldn't