Completion provides no results unless `[[` are typed

[WhyNotHugo]

Check if applicable

• [X] I have searched the existing issues (required)
• [X] I'm willing to help fix the problem and contribute a pull request

Describe the bug

When I manually invoke auto-completion, it won't provide any suggestions for inserting links.

Moreover, if using markdown style links, I still need to type [[ before the completion provider yields any results.

How to reproduce?

1. Invoke your text editor's autocompletion
2. You'll see no suggestions for inserting links

OR

1. Configure your notebook to use markdown style links.
2. Type [ and (optionally) manually trigger autocompletion.
3. You'll see no suggestions for inserting links

The root cause here is the completion provider only yields results in the two preceding characters are [[:

https://github.com/zk-org/zk/blob/4a51e398ae4572b2a1338fd9017ceeff30e5ffda/internal/adapter/lsp/server.go#L647

zk configuration

[notebook]
dir = "~/zk"

[note]
filename = "{{id}}"

[format.markdown]
hashtags = true
link-format = "[{{title}}]({{rel-path}})"

[lsp.diagnostics]
dead-link = "error"

### Environment

```bash
zk-0.14.1-r2
system: Linux 6.10.3-0-edge x86_64 Linux

[tjex]

Typing [[ is the default behaviour to trigger link completion though (for markdown links also, which is a little confusing). Regular markdown link completion ([title]( <-completion starts) is supposed to work, but has been found not to in #435, see context here in discussions.

As far as I'm aware, it was never designed that completion should work without any trigger / syntax context (e.g, manual completion).

But :ZkInsertLink suffices for link insertion in place of manual completion, or?

So I'm not sure if this is a "bug", but maybe edging more on a feature request?

I.e, that completion can be triggered manually and the LSP returns a list of links to insert?

[mickael-menu]

I had a quick look at the code and I think @WhyNotHugo is correct. An LSP client sends a "trigger kind" which can be invoked if the user hit a keyboard shortcut or trigger-character if known characters are typed, like [[.

The regression happened in this PR, but maybe @Rahlir had a good reason to check for [[ there. Do you remember why you changed the buildInvokedCompletionList implementation?

[Rahlir]

Hmm, it looks like this was part of the fix where previously the manual completion only worked with the # character, as you can see in this diff. So I don't think it is a regression per-say. However, I think I might have forgotten to check for links other than the wiki links. I will have a look at this this week and fix it, thanks for reporting this.

@tjex: Could you assign this issue to me so that I don't forget? Thanks.

[mickael-menu]

@Rahlir You're right, it couldn't have worked before either. I guess we could have a fallback on auto-completing links unless we're inside a tag (#).

[WhyNotHugo]

When a completion is manually requested, it's fine to suggest both links and tags.

In case of [[ (with wiki-style links) or [ (with markdownlinks), suggest only links.

In case of $TAG_PREFIX, suggest only tags.

Additionally, [[/[ should trigger completion.

[Rahlir]

When a completion is manually requested, it's fine to suggest both links and tags.

Interesting, so you mean that if you trigger manual completion when typing for instance note<cursor here> you would like to generate completion for both tags and notes containing word note in them? Because the intent of my previous commit was to only generate completions if the text contains either # (which would mean that the user is trying to complete tags) or [[ (which would mean that the user is trying to complete link - here was my mistake of forgetting other types of links). What you are suggesting differs from my intent. Although I am happy to do it this way. Although I am not sure what is the "more correct approach". What are your thoughts @mickael-menu @tjex ?

[mickael-menu]

There are also other types of tags, so maybe it's safer to just offer completion of everything, when we don't have a context.

[tjex]

I would agree. But I think links should take a higher priority in the LSP completion list (if there's currently support for that within our LSP implementation, or it's relatively trivial to implement). As most of the time, without any textual context, I would think users will be wanting to insert a link.

I also just checked, and I'm only getting tag completion for YAML tags. Hash or colon tags don't return anything. With colon tags set in .zk/config.toml

Caret in YAML array.

  1 ---
2   tags: [|]
  1 ---   ╭─────────────╮
  2       │ foo 󰉿 [LSP] │
  3       ╰─────────────╯

Carret after :.

  4 ---
  3 tags: []
  2 ---
  1
5   :|
~   ╭──────────────╮
~   │ tags 󰉿 [buf] │
~   ╰──────────────╯

So I think this part of the implementation from the PR needs some attention as well?

https://github.com/zk-org/zk/blob/4a51e398ae4572b2a1338fd9017ceeff30e5ffda/internal/adapter/lsp/document.go#L356C1-L358C3

[tjex]

Although the issue description isn't entirely matching, I'm pretty sure this should be fixed by #533

@WhyNotHugo If you could confirm, would be great, thanks. And cool to see your lsp_lines plugin being immortalised into neovim core 🥳

[WhyNotHugo]

I tested current main, which includes https://github.com/zk-org/zk/pull/533.

I don't see completion triggered when typing [something.

And cool to see your lsp_lines plugin being immortalised into neovim core 🥳

Thanks happy to see this upstreamed too!

[tjex]

[somethihng doesn't trigger completion [[ does.

But... It's still not really working for me. I don't get all my note being served up. It seems as soon as there is a white space in the title, it breaks... Getting the feeling like completion needs to be completely overhauled.

[WhyNotHugo]

It seems as soon as there is a white space in the title, it breaks

If I type a space, the completion pop-up is dismissed, but I believe that this is due to nvim-cmp, and not due to the LSP. I think keyword_pattern can be used to tweak this.

[artkpv]

I also have this: completion doesn't trigger unless [[. Also, I don't see completion for notes with Cyrillic titles (but latin slugs).

Example where links for Russian titles don't work. Creating a link by "[[", then "[[Способность]]" does not trigger completion

[WhyNotHugo]

I also see that if I type [[2025-11-05, it won't auto-complete an entry with filename (and title) starting in 2025-11-05, but all sorts of other entries which match the 2025-05.

It would be great if we could collect more samples of broken auto-completion (like the comment right above this one) so we can include them in tests and try to address all of them together.