Completion items not properly matching full 'word'
I suppose this is a continuation of #38. The issue reported there was resolved by 655d2ee2673950451a491294fd3ce7e17cfb0a24 but there is still an issue with the word selection logic.
The issue is that the replacement doesn't always match all the relevant text.
Example:
(ns example
(:require
[clojure.test :as test]))
(test/use|)
;; Press accept
;; Result:
(test/test/use-fixtures|)
;; Expected:
(test/use-fixtures|)
So it's not replacing the entire text of test/use it's just replacing the use component.
I wonder if the lsp completion items contain context about the range they are operating over.
Another example of this issue, still in clojure:
(ns example
(:require
[clojure.test :as scope.test]))
scope.te|
;; autocompletes to
scope.scope.test
I wonder if the lsp completion items contain context about the range they are operating over.
They typically do (textEdit field on completion items) but it sounds like clojure doesn't include these. It sounds like it instead passes through an insertText which gets converted into a textEdit interally here. I'm not sure how to handle this without writing custom context regexs (line 53) for each language.
It could be the LSP supports it, but disables the behavior, due to not broadcasting the capabilities correctly as per #13
I don't think its #13 as I copied over the capabilities config from nvim-cmp-lsp into my own config.
You're right about the textEdit - I did some inspection and it's not being set. I also took a peek at how nvim-cmp does it but it was too much to untangle and I didn't have much time.
But similarly to blink, nvim-cmp has a fallback to guess the range. At a glance It's implementation looks completely language agnostic so there is probably something there to base off of.
For reference:
Looks like there is this function to get the range: https://github.com/hrsh7th/nvim-cmp/blob/ae644feb7b67bf1ce4260c231d1d4300b19c6f30/lua/cmp/core.lua#L449
And then this plus a bunch of other functions for guessing the range: https://github.com/hrsh7th/nvim-cmp/blob/ae644feb7b67bf1ce4260c231d1d4300b19c6f30/lua/cmp/entry.lua#L316
Looks a bit gnarly to untangle
For my future self (or anyone who wants to implement this), the relevant piece on the nvim-cmp side is called by the function julien linked: https://github.com/hrsh7th/nvim-cmp/blob/f17d9b4394027ff4442b298398dfcaab97e40c4f/lua/cmp/entry.lua#L137-L160
We would need to implement similar logic here: https://github.com/Saghen/blink.cmp/blob/db3d1ad8d6420ce29d548991468cc0107fe9d04b/lua/blink/cmp/accept/text-edits.lua?plain=1#L102-L124
Yay!! Thanks! I'll give this a try later tonight.
Ah man it works! This has been blocking me from using this. Damn this plugin is so fast. You made my day, merry christmas and a happy new year :D
Hell yeah, love to hear it! Merry christmas and happy new year to you too :)
With v0.9.0 I still see ~ stays after the code snippet is selected / triggered. Plz lmk if it is a separated issue
@echaya This hasn't been released yet, but you can use main if you'd like to test it
Is this supposed to also work for snippets in C/C++ that contain the # character? Because if I type for example #ifndef and choose the snippet what gets inserted is
##ifndef MACRO <- tabstop placeholder
#endif
I'm on blink main by the way. I used to solve this by entering the characters I wanted into opts.completion.keyword.regex but I see that this has been removed. Is there an alternative for this?
PS: I just tested with Luasnip and I get the correct snippet output. This happens only with Neovim native snippets.
Hey @Saghen may I check when it will be released please? As I'm on RHEL and can't properly resolve the toolchains, awaiting it to be released. Thanks in adv!