Ensure that any keystrokes that are queued at picker launch are processed only
after the picker's mode (`insert` or `normal`) has been chosen, preserving
their intended meaning.
Previously the picker's mode was set by simulating keystrokes via `feedkeys()`.
In the absence of queued keystrokes, this works fine; but if the user is able
to queue keystrokes before the call to `feedkeys()`, those queued keystrokes
are processed before the simulated keystrokes that change the picker's mode.
Because of this unexpected ordering, the user's queued keystrokes may appear to
be ignored or may cause the picker to start in the wrong mode.
For example, consider the below normal-mode mapping:
```vim
:nnoremap <space>ff :Telescope find_files<CR>
```
Upon launching the picker via `<space>ff`, Neovim is already in normal mode.
To switch to insert mode in the picker, Telescope previously used a call to
`feedkeys("A")`, simulating a keypress of `A` to enter insert mode at the end
of the current line. This `A` will not be processed until all previously
queued user keystrokes have been processed, causing issues.
In real-world use, problems occur when the user types `<space>ff` followed
quickly by characters intended as fuzzy match text. This can be demonstrated
using `feedkeys()` as shown below.
```vim
:call feedkeys("\<space>ff" . "apple")
```
The user intended to search for `apple`, but the `a` is mis-interpreted as a
request to enter insert mode at end of line, after which `pple` is inserted;
subsequently, Telescope's simulated `A` is then appended, resulting in a search
string of `ppleA`.
Using `:startinsert!` (to enter insert mode as if by `A`) or `:normal! $` (to
enter normal mode and move to end-of-line) avoids interfering with the user's
queued keys.
Fixes#2274.
* Fix tagrelative option not considered in builtin.tags
* Fix wrong notify name
* ctags filtering with grep or rg and normalize path
* pass stylua check
---------
Co-authored-by: James Trew <j.trew10@gmail.com>
59497d6 introduced `sorters.fuzzy_with_index_bias`, which gives a
scoring boost to earlier entries.
However, this sorter relies on an `index` key existing for the entry, which is
only populated by the static finder currently. We should set it from the
other finders, too.
This will allow us to use said sorter everywhere. It will also let us
replicate the behaviour of `fzf --tiebreak=index`:
```
return pickers.new(opts, {
finder = finders.new_oneshot_job(...)
sorter = telescope.extensions.fzf.native_fzf_sorter(),
tiebreak = function(current_entry, existing_entry, _)
return current_entry.index < existing_entry.index
end
}):find()
```
This gives me better results for my "recently opened files" picker.
Other builtin pickers might benefit from this, too.
Fix the problem I reported in <https://github.com/nvim-telescope/telescope.nvim/issues/1725#issuecomment-1502548033>.
Supporting the abbreviations of the commands to specify the direction makes too
many combinations, so I added only their unabbreviated names.
In addition, make the error message more detailed for users that passes
unsupported command.
