Incorrect handling of special characters in completion items

[julienvincent]

Make sure you have done the following

• Updated to the latest version of blink.cmp
• Searched for existing issues and documentation (try <C-k> on https://cmp.saghen.dev)

Bug Description

Issue 1 - Resolved by 4c7ab7a!

Blink behaves weirdly if completion items contain special characters.

I'm sure the clojure language is a pretty good stress test for blink because clojure vars can and do contain a larger range of 'special' characters than other languages.

A very common one is the ! character to indicate mutation or side-effects and -> or >/< characters.

For example if I have a lib exporting the following:

(ns example.lib)

(defn ->thing [])

(defn do-something! [])

(defn do-something [])

and try autocomplete it as follows:

(ns example
  (:require 
    [exmaple.lib :as lib]))

(lib/|)

Then I only see:

lib/do-something

When I would expect to see all three exported vars.

If I comment out the do-something export then, surprisingly, I see the special-character exports:

;; example/lib.clj
...
;; (defn do-something [])
...

;; example.clj
lib/do-something!
lib/->something

Issue 2

Trying to accept the suggestions of either of the two above items containing special characters results in incorrect content being inserted into the buffer:

(lib/lib/do-something!)

This seems to be #46 raising its head again, though limited to special characters.

---

I recorded a short vid to demonstrate:

special-chars.mov

Just to be super explicit, I'm going to explain:

1. The first autocomplete attempt shows only do-something when it should show all three exported functions. Accepting it does inserts the correct content into the buffer, which is good.
2. Commenting out do-something as an exported var in the lib module results in both the two special-character containing exports to now show as expected.
3. Accepting either of them inserts the incorrect content into the buffer (double-prefixed with their lib/ identifier).
4. Attempting to auto-complete after the > character hides the autocompletion menu when, for clojure, I expect it to remain. This should still be considered a keyword (should this be made configurable in blink?)

Relevant configuration

No response

neovim version

0.10.2

blink.cmp version

main

[julienvincent]

I guess this is kinda multiple issues in one, but they are all somewhat related I think so leaving it bundled to not make more noise. I am happy to break this into multiple issues though if you prefer. Let me know!

[SuzumiK]

I think what I see is the same issue (or at least related), but in this case with function parameters that contain special characters (dots/periods):

1. Typing legend shows available parameters. Note it includes legend.key and legend.key.height
2. With legend.key, legend.key.height is no longer offered as completion.
3. Continuing to type legend.key.s... showing legend.key.size and legend.key.spacing. Once the prefix includes a special character, blink appears to only look back to the previous special character.
4. Inserting only replaces the typed siz prefix, duplicating legend.key

The language is R, set iskeyword? includes "."

[rodnaph]

Unsure if this is the same issue, but when using the Intelephense LSP with PHP I'm not seeing functions/namespaces included in the completion menu (and PHP oddly uses a backslash for namespace separator). This works with nvim-cmp, so I'm assuming the info is being returned by the LSP, but then not included for some reason by Blink.

Disclaimer: I'm a total beginner with LSP stuff so might not be formulating the description correctly, and am at a loss as to where to look for the issue...

Edit: Still unsure if related, but my particular issue seems to come from the Rust fuzzy finding here, where setting min_score to 0 means I see results returned for namespaces/functions (but the results are not well sorted, so contains lots of noise).

blink.cmp/lua/blink/cmp/fuzzy/init.lua

Line 82 in 2144c58

min_score = config.fuzzy.use_typo_resistance and (6 * keyword_length) or 0,

Any tips on where to look next appreciated.

[julienvincent]

Hey @Saghen looks like 4c7ab7a solves the visibility issues for me. The insertion issue bug is still around - but looks like #1067 has been opened since which seems to track the same issue.

[julienvincent]

I updated the title and issue description to clarify there are two main issues listed here. Should make it easier for people reporting similar issues to find this.