* feat(lsp_definitions): adding `tab drop` as `jump_type`
* feat(lsp-jump-types): `tab drop` for LSP features
Now, you're able to use `tab drop` as `jump_type` for these LSP
features: references, type definitions, definitions an implementations.
* fix(docs): reordering `tab drop` option
* feat: generate docs
* fix: nil problem with `vim.uri_to_fname`
* fix: removing warning about `file_uri` variable not being used
---------
Co-authored-by: Simon Hauser <simon.hauser@helsinki-systems.de>
With this change we will check if the provided buffer number is valid,
before querying its `buftype` option. This is necessary, because
currently we would fail with:
```
Error executing vim.schedule lua callback:
...scope.nvim/lua/telescope/previewers/buffer_previewer.lua:473:
Invalid buffer id: X
```
error, if we try to resume a jumplist picker after doing `:bwipeout`.
This commit fixes the following error:
E5108: Error executing lua: Vim:Can't send data to closed stream
stack traceback:
[C]: in function 'chansend'
/lua/telescope/previewers/term_previewer.lua:224: in function '_send_input'
/lua/telescope/previewers/previewer.lua:85: in function 'send_input'
/lua/telescope/previewers/term_previewer.lua:238: in function '_scroll_fn'
/lua/telescope/previewers/previewer.lua:93: in function 'scroll_fn'
/lua/telescope/actions/set.lua:249: in function 'run_replace_or_original'
/lua/telescope/actions/mt.lua:65: in function 'scroll_previewer'
/lua/telescope/actions/init.lua:222: in function 'run_replace_or_original'
This happens when previewers.new_termopen_previewer()'s get_command()
ends without pagination.
The cursor layout uses winline() and wincol() to calculate the cursor
position. Both these functions operate on the currently active window.
The first time the calculations are performed, that happens to be the
window active before showing the Telescope window. However, if the
editor is then resized or the preview window is toggled, the active
window changes. The result is that recalculating the position is then
done using the wrong window, resulting in the Telescope window moving
around in an erratic manner.
To fix this, we have to scope the winline() and wincol() calls to the
original window ID.
The only possibility for having a table with different severities to
pass to `vim.diagnostics.get()` as opts is when setting a range (limit
and bound), so just check for an empty table when a range is set.
* fix(telescope.state.get_existing_prompts): it should only return keys that are numbers
* Table keys not table values should be numbers
* Rename get_existing_prompts to get_existing_prompt_bufnrs and make the impl more efficient
* fix: use nil for the default diagnostics severity
https://github.com/neovim/neovim/pull/24736 has introduced a new syntax
for severity format in `vim.diagnostic.get()`.
Fix#2661
* fix: fallback for 0.9.1
* fix: detect changes only when minor version > 9
When filtering is applied, `picker:get_index(picker:get_selection_row())` returns index relative to the filtered entry list rather than the original full results. This causes inaccurate indexing into the `cache_pickers` table.
For some git actions pressing Esc for the dialog of action confirmation
didn't cancel the action. I moved asking for confirmation to a separate
function and a bit changed notifications about canceled action.
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.
