[mini.pick] Input motions

[drowning-cat]

Keymaps:

• <C-Left> / <C-Right> like in Insert mode, respecting vim.bo.iskeyword
• <Home> / <End> like in Insert mode (overrides move_start, see comment)
• <C-S-Left> / <C-S-Right> similar to <C-Left> / <C-Right> in Cmdline

pick-motions.mp4

local run_keys = function(keys, rep)
  vim.api.nvim_input(string.rep(keys, rep or 1))
end

local move_caret = function(next_caret)
  local caret = MiniPick.get_picker_state().caret
  local query = MiniPick.get_picker_query()
  next_caret = math.max(1, math.min(next_caret, #query + 1))
  local move = next_caret - caret
  run_keys(move >= 0 and "<Right>" or "<Left>", math.abs(move))
end

require("mini.pick").setup({
  mappings = {
    -- Easy
    caret_start = {
      char = "<Home>",
      func = function()
        move_caret(1)
      end,
    },
    caret_end = {
      char = "<End>",
      func = function()
        -- TIP: You can also use `math.huge` instead
        move_caret(#MiniPick.get_picker_query() + 1)
      end,
    },
    -- Medium
    -- Like <C-Left>/<C-Right> in Cmdline, but skip spaces
    prev_before_space = {
      char = "<C-S-Left>",
      func = function()
        local query_str = table.concat(MiniPick.get_picker_query())
        local caret = MiniPick.get_picker_state().caret
        local search_str = string.sub(query_str, 1, caret - 1)
        local word_start = string.find(search_str, "%S+%s*$")
        move_caret(word_start or 1)
      end,
    },
    next_before_space = {
      char = "<C-S-Right>",
      func = function()
        local query_str = table.concat(MiniPick.get_picker_query())
        local caret = MiniPick.get_picker_state().caret
        local word_end = string.find(query_str, "%f[%s]", caret + 1)
        move_caret(word_end or #query_str + 1)
      end,
    },
    -- Hard
    -- Like <C-Left>/<C-Right> in Insert mode, vim.bo.iskeyword
    prev_word = {
      char = "<C-Left>",
      func = function()
        local query_str = table.concat(MiniPick.get_picker_query())
        local caret = MiniPick.get_picker_state().caret
        -- TIP: To avoid recompiling regex on each key press, move it outside the `func`
        -- NOTE: ((not keyword and not space)+ OR keyword+)space*$
        local regex = vim.regex([=[\([^[:keyword:][:space:]]\+\|\k\+\)\s*$]=])
        local from, _ = regex:match_str(string.sub(query_str, 1, caret - 1))
        local prev_word_start = from and from + 1 or nil
        move_caret(prev_word_start or 1)
      end,
    },
    next_word = {
      char = "<C-Right>",
      func = function()
        local query_str = table.concat(MiniPick.get_picker_query())
        local caret = MiniPick.get_picker_state().caret
        -- NOTE: ^((not keyword and not space)+ OR keyword+)space*
        local regex = vim.regex([=[^\([^[:keyword:][:space:]]\+\|\k\+\)\s*]=])
        local _, to = regex:match_str(string.sub(query_str, caret))
        local next_word_start = to and to + caret or nil
        move_caret(next_word_start or #query_str + 1)
      end,
    },
    -- stylua: ignore start
    caret_start_alt = { char = "<C-a>", func = function() run_keys("<Home>") end },
    caret_end_alt = { char = "<C-e>", func = function() run_keys("<End>") end },
    move_down_alt = { char = "<C-j>", func = function() run_keys("<C-n>") end },
    move_up_alt = { char = "<C-k>", func = function() run_keys("<C-p>") end },
  },
})

[drowning-cat]

I hope mini.nvim will include:

• <Home> / <End>
• <C-Right> / <C-Left> (with iskeyword support)

---

TL;DR

it is in the "not planned" list at the moment.

See #2169 (reply in thread).

[echasnovski]

1. Using PageUp for move_start makes more sense to me.

<PageUp> is more like scroll_up action.

Wouldn’t it be easier to press <C-Left> a few times followed by <C-w>?

Easier - probably. Doing something that is not currently possible - no. Expanding 'mini.pick' only for something very high leverage is a high priority right now. Mostly due to the module's size.

Also, regarding refining, is there a way to jump back to the previous refinement?

I am afraid, no. That would add memory footprint and code complexity. And there is no good default key for that which is universally supported enough.

[drowning-cat]

<PageUp> is more like a scroll_up action.

Makes sense. But even in normal mode, <Home> and <End> don’t jump to the first and last columns.

That would add memory footprint and code complexity.

I don’t think memory footprint is an issue unless all entries are saved—saving only the query should be enough. But I haven’t looked at the code, so it’s really stupid for me to argue.

And there is no good default key for that which is universally supported enough.

I would use "Control/Alt + Arrow" keys.

I guess implementing such a feature would only make sense if at least a few people needed it, not just me. I just hope it doesn’t get thrown into the "not to do" bucket, but at least into the "maybe to do" list. Personally, I can always keep these mappings in my own configuration.

[echasnovski]

I guess implementing such a feature would only make sense if at least a few people needed it, not just me. I just hope it doesn’t get thrown into the "not to do" bucket, but at least into the "maybe to do" list. Personally, I can always keep these mappings in my own configuration.

If you mean mappings from this discussion - it is in the "not planned" list at the moment.

If you mean "previous refine" - it is in the "probably not planned" list at the moment.

[drowning-cat]

One extra problem here is that query technically can contain not only single letters, but whole words. So full "word" navigation is not always possible since caret can be placed only in between query entries.

So if a table of characters is needed, then vim.split(table.concat(query), '') should be enough?

Oh, if the query is { "a", " ", "bcd", "e" }, it will still be shown as a bcd|e (caret is 4), but pressing <Left> will jump over bcd to the space?

[echasnovski]

Oh, if the query is { "a", " ", "bcd", "e" }, it will still be shown as a bcd|e (caret is 4), but pressing <Left> will jump from bcd to the space?

Yes. Because it is a single query entry.

[echasnovski]

Thanks for sharing!

Note that <Home> is a built-in mapping that will always be there as an alternative to move_start action. So mapping it to move_caret(1) will probably be ambiguous.