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
`nvim_feedkeys(simulated_keypresses, "n")`. In the absence of queued
keystrokes, this works fine; but if the user is able to queue keystrokes
before the call to `nvim_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 `nvim_feedkeys("A", "n")`, simulating a keypress of `A` to
enter insert mode at the end of the current line. This `A` would 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 `nvim_feedkeys()` as shown below.
```vim
:call nvim_feedkeys("\<space>ff" . "apple")
```
The user intended to search for `apple`, but the `a` is misinterpreted
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`.
To ensure that Telescope's simulated keypresses are processed first, an
additional `i` flag is now passed to `nvim_feedkeys()`, causing the
simulated keypresses to be inserted at the start of the typeahead buffer
ahead of any user keystrokes.
Fixes#2274.
* Filter bcommits by selection in visual mode
* Split bcommits_range into new picker
* Add option to run bcommits_range as operator
Starts operator-pending mode and shows commits in the range of lines
covered by the next text object or motion
* Rename range arguments to "first" and "last"
Can't use start/end, since end is an annoying keyword to use in lua
and start/stop doesn't fit as well
* Move operators functionality to new module
* Run bcommits if no range given to bcommits_range
* Make bcommits_range default to current line
Instead of calling bcommits
* Improve documentation of telescope.operators
* Add default value for last_operator
Default to a no-op callback
* Update bcommits_range for detached worktrees
See #2597
* Rename range arguments to "from" and "to"
* Move shared bcommits picker into single function
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.
