snippet_forward is still triggerable after user has moved on

[BirdeeHub]

possibly related issue #1666

related configuration:

keymap = {
    -- ...
    ['<Tab>'] = { 'snippet_forward', 'fallback' },
    ['<S-Tab>'] = { 'snippet_backward', 'fallback' },
    --- ...
},

When I choose a snippet in the completion menu, replace the fields from the snippet I want, and then go on to edit other things, the snippet will hang around as open.

This means that after accepting a snippet and editing it as required, I then go to edit more text somewhere else in the file, hit tab to enter a tab character and then it instead jumps me alllllll the way back to where the last snippet I accepted was.

Would there be a way to tell blink that I am done with said snippet after my cursor moves outside of the snippet's line range?

Obviously the workaround to do for now would be to just use a different key so that it interrupts a less important action, but this still would apply to any key I do choose.

If you don't wish to change the behavior of snippet_forward or adding options for more generally making keys bound to their area, adding a bounded_snippet_forward and bounded_snippet_backward would be enough?

[HusuSama]

Same issue encountered here. #1809

[BirdeeHub]

Addendum

It does not seem happen if you tab through all the options actually

But the reason I was confused is that if you go through several snippets without tabbing through them all, they will stack up it seems, and it might also happen with signature help, unsure.

[saghen]

This isn't handled by blink.cmp but rather by your snippet engine. The :h vim.snippet engine for example will remain active until you enter insert mode outside of the bounds and on a different line, than the snippet you expanded. You can control this programmatically with vim.snippet.stop so i.e. you could have the snippet session stop when you exit insert mode by creating an autocmd.

vim.api.nvim_create_autocmd('InsertLeave', { callback = vim.snippet.stop })

-- you can check if a snippet session is active with vim.snippet.active()

Personally, I've mapped it to <Esc> alongside noh:

vim.keymap.set('i', '<esc>', '<cmd>noh<cr><esc>', { silent = true, desc = 'Escape and clear hlsearch' })
vim.keymap.set({ 'n', 's' }, '<esc>', function()
  vim.cmd('noh')
  vim.snippet.stop()
  return '<esc>'
end, { silent = true, expr = true, desc = 'Escape and clear hlsearch/snippet' })

Feel free to discuss further but since this isn't an issue with blink.cmp and moreso some unexpected behavior from the vim.snippet engine in particular, I'll close this. You may want to try alternate engines like mini.snippet or luasnip (the former in paritcular may do what you're expecting OOTB)

[BirdeeHub]

I am using luasnip already

I never experienced this with luasnip and nvim-cmp and it is quite annoying.

If this ends up being due to signature help and not snippets, should I open a new issue with the correct name?

[saghen]

It's not due to signature help, but you can customize when blink.cmp treats the snippet as "active" from the snippet engine via snippets.active = function() return bool end. You can see the values from the presets here: https://github.com/Saghen/blink.cmp/blob/main/lua/blink/cmp/config/snippets.lua#L43

If you find a function that works for you, please share it here! I'll give it a try

[soifou]

@BirdeeHub, all the behavior you describe is because LuaSnip creates a "snippet session" and will only stop this session if you go through all the tabstops. Canceling the session is left up to the user.

So I am a bit surprised that nvim-cmp cancels the LuaSnip session itself. I don’t see any mention of that in the actual code.

Anyway, the workaround is to cancel this session when nvim detects a mode change (e.g., going from select to normal). You can find it here: L3MON4D3/LuaSnip#258 (comment)

Let me know if this works for you.

[HusuSama]

@soifou @BirdeeHub

I've configured blink.cmp directly with the following settings. While I haven't encountered any issues so far, I suspect my testing scenarios might not be comprehensive enough😥:

return {
  "saghen/blink.cmp",
  opts = function(_, opts)
    ---@type blink.cmp.KeymapConfig
    opts.keymap = {
      preset = "super-tab",
    }
    return require("astrocore").extend_tbl(opts, {
      sources = {
        per_filetype = { sql = { "dadbod" } },
        providers = {
          dadbod = { module = "vim_dadbod_completion.blink" },
        },
      },
      ---@type blink.cmp.CompletionConfig
      ---@diagnostic disable:missing-fields
      completion = {
        list = {
          selection = { preselect = true, auto_insert = false },
        },
      ---@type blink.cmp.SnippetsConfig
      snippets = {
        -- preset = "luasnip",
        active = function(filter)
          local snippet = require "luasnip"
          local blink = require "blink.cmp"
          if snippet.in_snippet() and not blink.is_visible() then
            return true
          else
            if not snippet.in_snippet() and vim.fn.mode() == "n" then snippet.unlink_current() end
            return false
          end
        end,
      },
    })
  end,
}

[BirdeeHub]

Nice! I will be at home sometime tonight and will be able to test it out 😊

[NobbZ]

@HusuSama's solution seems to "work" for me, in the sense that I do not get randomly jumping cursors anymore, though I also can not navigate anymore between snippet "holes".

Instead using the cursor keys just go up and down instead, rather than next/prev "hole".

Maybe I am missing something?

NobbZ/nobbz-vim#69

---

I only did a very surface level test, not a thurough one. I will do more and deeper testing beginning on monday when I am actually doing real code work, rather than small toy code bases.

[BirdeeHub]

https://github.com/BirdeeHub/birdeevim/blob/7815e3e6dffbf13a5e7a0816e8cf7e556720c0b5/lua/birdee/plugins/blink.lua#L124-L136

        ---@type blink.cmp.SnippetsConfig
        snippets = {
          preset = "luasnip",
          active = function(filter)
            local snippet = require "luasnip"
            local blink = require "blink.cmp"
            if snippet.in_snippet() and not blink.is_visible() then
              return true
            else
              if not snippet.in_snippet() and vim.fn.mode() == "n" then snippet.unlink_current() end
              return false
            end
          end,
        },

This as a top level attribute does seem to work well for me.

If I remain in insert mode, I can tab between them, and if I leave insert mode it no longer does, solving my issue.

Thanks for all the attention on this y'all, I got busy this week but I really should have gotten around to testing that sooner because that was easy thanks to the suggestions.

As far as your up and down keys thing, Im not sure, I have a weird set of keybinds I use

[NobbZ]

Hmm… I will play with using <Tab>/<S-Tab> for snippet movement next week, when I am doing actual work, maybe it was just something with my toy code base?

[Knaifhogg]

Using the autocommand or the active function seems to break snippets for me, so if I complete a snippet suggestion I can't tab to progress. Tested both in Rust and Markdown. I use default keymap with Luasnip preset, so I expect to press ctrl + y to complete, then tab/s-tab to jump between snippet items. If I move away mid-snippet usage to somewhere else, enter insert mode and press tab, I get thrown back to where the previous snippet was.