Allow opening of a picker with default text selected in **select** mode

[rkoval]

Is your feature request related to a problem? Please describe. I imagine this request is weird/unconventional because select mode (and not just visual mode), so apologies for that. I blame other editors for conditioning me this way :)

I am used to behavior where a search dialog is pre-populated with the last input provided. This input is then highlighted to either search again or allow you to type over it immediately without any special hotkeys. This allows me the option to open the picker with the same keymap to either a) reuse the previous input string for a new search, optionally editing it if i need to; or b) start a new search seamlessly by typing as if the buffer was empty (that is, no extra keypresses to contextually remember to do to clear the prompt)

Telescope provides the picker option default_text that I've been able to use to solve the first part of the problem. However, it doesn't look like Telescope provides the means to enable solving the second part of the problem since it seems the plugin is limited to just insert and normal mode.

Describe the solution you'd like Allowing for passing initial_mode = 'select' in the picker configuration. I am not sure if it makes sense to pass in a separate, explicit config option to highlight all of the input, or if just specifying initial_mode = 'select' would be enough to implicitly select the whole buffer (because it seems like select mode would otherwise be worthless if there was nothing highlighted)

Describe alternatives you've considered Setting initial_mode = 'normal', and then in the attach_mappings hook, programmatically entering visual mode, selecting the whole line, and then switching to select mode somehow? This feels like a huge hack though, and I'm not actually sure if this is even possible given that I am very new to Lua and NeoVim's API 😅

Additional context This plugin is amazing!!!!!!! Thank you so much for your hard work!! 🙏 Please let me know if what I'm describing is not making sense

[fdschmidt93]

The hack would be something like this

builtin.find_files({
  default_text = "test",
  on_complete = {
    function(picker)
      local mode = vim.fn.mode()
      local keys = mode ~= "n" and "<ESC>" or ""
      vim.api.nvim_feedkeys(vim.api.nvim_replace_termcodes(keys .. [[^v$<C-g>]], true, false, true), "n", true)
      -- should you have more callbacks, just pop the first one
      table.remove(picker._completion_callbacks, 1)
    end,
  },
})

I'm a bit wary of adding it as a default mode because other mappings don't work as expected and the above snippet seems to work as intended.

[rkoval]

Ahh very cool! Thank you for the snippet! This seems to solve my issue nicely after some tweaks. Feel free to close this out 👍

[fdschmidt93]

Glad to hear it works well, I suppose thats preferred over having to maintain select as an extra initial mode 😅 Closing as resolved :)

[rkoval]

Hey again, @fdschmidt93 - I'm wondering how I would go about defining mappings for select mode with this new configuration? The mappings property within telescope config seems to only support normal and insert mode?

[fdschmidt93]

As per the above example, something along the lines of

builtin.find_files({
  default_text = "test",
  on_complete = {
    function(picker)
      local prompt_bufnr = picker.prompt_bufnr
      vim.keymap.set('s', lhs, rhs, { buffer = prompt_bufnr })
    end,
  },
})

should work.

[rkoval]

Thanks for these snippets! I've been able to map select mode keymaps after some tweaks.

However, an issue that I keep running into with the original snippet you posted for me is that vim.api.nvim_feedkeys can sometimes lag in this on_complete callback. That is, I open telescope, start typing, but the select mode vim.api.nvim_feedkeys call hasn't actually executed yet, and then my original input is cut off. I then have to retype the whole string and/or close/reopen telescope to reinitialize it. Is there anything you can advise to avoid this?

Looking at the source, I'm wondering if it makes sense to add an additional hook somewhere in this function (or elsewhere) that would resolve this issue more generically? I am unsure if this the functions above self:_on_complete() would have conflicts with a new hook like that though

[fdschmidt93]

Looking at the source, I'm wondering if it makes sense to add an additional hook somewhere in this function (or elsewhere) that would resolve this issue more generically? I am unsure if this the functions above self:_on_complete() would have conflicts with a new hook like that though

I'm not sure I 100% follow. self:_on_complete de facto is the table of functions passed as { on_complete = { function() ... end, function() ... end } What other callback would you expect here? See also what follows

However, an issue that I keep running into with the original snippet you posted for me is that vim.api.nvim_feedkeys can sometimes lag in this on_complete callback. That is, I open telescope, start typing, but the select mode vim.api.nvim_feedkeys call hasn't actually executed yet, and then my original input is cut off. I then have to retype the whole string and/or close/reopen telescope to reinitialize it. Is there anything you can advise to avoid this?

I can reproduce this when eg trying to launch find_files from home with selection mode completion callback. I presume the problem is.. the finder is just not completed.

I think the appropriately generic solution would be to replace this autocommand

https://github.com/nvim-telescope/telescope.nvim/blob/3d304a9a55f1b142b874c319138152003f192c4c/lua/telescope/pickers.lua#L345-L346

with a function that can be passed as picker startup (I'm not sure autocommands are suitable here because they are picker agnostic). Then users could pass global defaults and picker overrides in telescope.setup. (We have a similar issue with TelescoperPreviewerLoaded https://github.com/nvim-telescope/telescope.nvim/issues/1661#issuecomment-1154388502). And doesn't seem like anyone is making use of that autocommand anyways: sourcegraph. With the dev-branch, now would be a good time to introduce such a change. Would you be happy to make a PR for that? :) Should be relatively straightforward

[Conni2461]

I think the appropriately generic solution would be to replace this autocommand

I want a proper event system for quite some time and had this on my plan for 0.2. Like having events literally for almost everything. If we have a proposal ready for 0.1 thats great but its not that high on my priority list

[rkoval]

With the dev-branch, now would be a good time to introduce such a change. Would you be happy to make a PR for that? :) Should be relatively straightforward

I can try to give this a shot soon!

Just clarifying I have the right understanding though being so new to this: wouldn't the change have to invoke the hook sometime after this line because the callback otherwise wouldn't have reference to the prompt buffer for feeding keys (or modifying in any other way) if called in the same spot as the previous autocommand?

Follow-up question: if the above is true, since it's so close to this, would you hate me/reject the PR if it also included first class support for select mode by basically just feeding keys to switch to select mode like you suggested (which seems similar to how normal mode is switched to in that same code block)? It does seem like I'm not the only one that wants this functionality based on the backlink from #1766, though I definitely understand maintenance overhead and all that, so I'll respect your wishes and won't push if you are still against it.

[fdschmidt93]

would you hate me/reject the PR if it also included first class support for select mode by basically just feeding keys to switch to select mode like you suggested (which seems similar to how normal mode is switched to in that same code block)?

Select mode and the revamped callback/event system should be two separate PRs. I'd welcome to a select mode PR since I better understand use cases for it now.

if the above is true, since it's so close to this

General side note as means of background: proximity in these lines of code heavily matters as per the neovim / telescope event loop. I actually suppose support select mode is probably best embedded by incorporating it as an appropriate initial mode after 3mins of playing around, because otherwise there's multiple mode changes that don't necessarily schedule well within the event loops.

Consequently we'd imo need two PRs to fully embed this functionality:

• initial_mode = "select" - this needs to work in a lot of scenarios, cf. table of this PR
• "proper event system" - to be clarified. Either appropriately via vim autocommand system or passing functions similar to e.g. require 'telescope.builtin'.find_files { on_complete = { function(picker) ... end }

initial_mode may already suffice as you maybe can also attach_mappings to select mode, I haven't tried it.