Completions not always displayed to users

Get Help
1

I’m having an issue where provideCompletionItems is being triggered, but the returned options are not displaying depending on what precedes the identifier characters. More specifically, if someone desires the completion ‘latest’, then they’ll see options if their input is :l, but not if their input is : l. I have space as one of my triggerChars, but that doesn’t seem to have an effect.

I’m not sure if this is a bug, or if there is some logic behind the different outcomes. I’d love to know what causes provided CompletionItems to be suppressed from displaying to users.

2

So… I’m alone in having this problem? This wasn’t an issue in Nova 1. I’d really appreciate some help in taking the guesswork out of getting suggestions for my extension users.

3

Hello Drew,

We haven’t had reports of this from any other users yet, correct.

I assume you are specifying the trigger characters on the assistant registration like so?

nova.assistants.registerCompletionAssistant("html", new CompletionProvider(), {
    triggerChars: new Charset(": ")
});

Providing a code sample (or linking to a project repository) would help us diagnose what might be happening.

4

Thanks for offering to help! Correct, this is my assistant registration:

nova.assistants.registerCompletionAssistant(
  'json',
  new NpmCompletionAssistant(),
  { triggerChars: new Charset(': "^~') }
)

As I mentioned above, the provideCompletionItems method is being triggered, but the results I return aren’t displaying.

Here’s my repo. I apologize for not having a README, but npm install && npm run build should be enough if you want to build the project for testing.

EDIT (Aug 30): I have since merged the branch I referred to earlier, so I updated the link to point to the main repo page.

5

I finally had time/energy to bang on this recently. My current theory is that I was trying to helpfully format completions in this JSON document with JSON punctuation (e.g., " :,), and having any of those as initial characters was causing the completion to be suppressed. I got the sense that I was doing it wrong and needed to find a better approach.

In my particular case, I was able to find a solution by completing with Snippets instead of plain text. Something about the completion being within a snippet got around the issue I was experiencing, and as a bonus offered a better extension experience for my users.

I’d still really appreciate any clarity Panic could bring to why completions might not be displayed.

6

@logan I think I encountered similar issue while trying to bring native Tailwind LSP integration.
Tailwind classes are usually separated by - (hyphens), so trying to narrow down the results by continuing to type actually dismisses the autocompletion suggestion entirely.
And given that this is just out of the box LSP extension, I don’t think I’ve access to configuration of the triggerChars.
Same behaviour occurs in both HTML and TSX files.

Happy to start a separate thread if this is unrelated though.
Thanks!

1 Like
7

Correct, yeah. For LSP integrations, on startup the language server tells Nova what characters should trigger autocomplete, and then Nova tries to respect that (unless the user explicitly turns off “show completions for server-defined characters” in Nova’s preferences). This will just affect whether Nova sends an LSP request. It won’t affect how the language server actually computes the results.

From the look of your screen recording, it’s not entirely clear for me right now whether the - hyphen character is not causing the list to show, or whether the LSP might not be returning any results in that case. From debug logging of the language server, do you know which it is?

If it’s just the former (the list not being shown for the hyphen) then yeah, there isn’t currently a way to affect that character set because it’s sent to Nova dynamically on startup from the language server. We could consider a way to override this, though.

8

Seems like the LSP does set hyphens as triggerCharacters.

I unfortunately wasn’t able to get anything logging by attaching handlers for client.onNotification("textDocument/completion", …, but I haven’t worked with LSPs at all so could be missing something. If you could provide a general pointer in the right direction would be happy to explore further, otherwise if you’re able to try yourself, the extension is open source GitHub - alex-ketch/Nova-Tailwind-LSP: ⚠️ WIP — Not ready for use.

Regarding whether the completion is empty or not, hard to say, but it seems to treat hyphens as a separator. Reason I say this is the typing border- dismisses the completion list even though there are other valid options (e.g. border-4).
Then manually requesting completion items with cursor at border-|, offers an entirely fresh set of completions for values starting with - instead of border-.

9

Yeah. This is a bit what leads me to believe the language server isn’t returning the proper results in this case. If the hyphen is included, it should be attempting results. But moreso, since invoking autocomplete after the hyphen returns results that start with a hyphen this leads me to believe the Tailwind language server may not be handling hyphens correctly, since you’d think it would properly consider the characters before the hyphen, too. And with the way LSP completions work, Nova isn’t sending a string to complete to it—it’s just sending the character position in the file.

10

In attempting to narrow this down, I tried comparing behaviour between Nova and Vim.
I configured Nova’s extension to use same initializationOptions as the Vim LSP found here.
Both should be delegating to the same LSP server, but as you can see the issue only happens in Nova.
I tried disabling the setting in Nova for Accept completion on server-defined characters, but that didn’t affect anything.

Enabling debug mode yields logs now, but Nova freezes up almost immediately when trying to log events for a completion trigger. And no sign of recovery after several minutes.
Assuming culprit is same as before.

I’d love to be able to solve this, but I don’t know if there’s much else information I can provide to get to the bottom of this given the inability to see the LSP logs.
Are there any other data points, or things I can try, that might be of help to you @Logan?
Either way, thank you for your time and input!