Pass `core.quotepath=false` to achieve this.
Could alternatively pass `-z` but that uses `\0` line termination and
complicates things.
Closes#2900
(cherry picked from commit 955e50dfed)
`vim.fn.matchstrpos({expr}, {pat})` doesn't handle all characters well
since the pattern (cwd path in this case) is used as a regex pattern.
(cherry picked from commit b3ff5f3320)
Previously, using `string.find`, certain characters were taken as regex
special characters leading to bad matches.
New approach takes bufname truncated to the length of cwd and compares
the two strings.
(cherry picked from commit 8b56e9bb2d)
closes#2843
Previously, bad partial matches between cwd and target buffer path would
result in non-cwd buffers showing up in the picker despite using
`only_cwd=true`.
eg.
cwd = `/foo/bar`
target buffer = `foo/bar1/baz.txt`
The target buffer starts with the cwd path.
This is fixed by appending a path separator before comparing/matching:
eg.
cwd = `/foo/bar/`
target buffer = `foo/bar1/baz.txt`
(cherry picked from commit c621f71012)
* Add autocmd to make `which_key` window close on prompt exit
Currently `actions.which_key` supports a `close_with_action` option
(default true). When this is set, the `which_key` window will close
after any Telescope action is triggered. This makes sense. However, when
it is false, the `which_key` window remains open even after Telescope
closes. This seems like a bug.
This PR fixes this by setting an autocommand when `close_with_action` is
false to close on prompt exit.
* [docgen] Update doc/telescope.txt
skip-checks: true
* Add autocmd to make `which_key` window close on prompt exit
Currently `actions.which_key` supports a `close_with_action` option
(default true). When this is set, the `which_key` window will close
after any Telescope action is triggered. This makes sense. However, when
it is false, the `which_key` window remains open even after Telescope
closes. This seems like a bug.
This PR fixes this by setting an autocommand when `close_with_action` is
false to close on prompt exit.
---------
Co-authored-by: Github Actions <actions@github>
(cherry picked from commit ae6708a90b)
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`.
(cherry picked from commit 4522d7e3ea)
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.
(cherry picked from commit a62db885fd)
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.
(cherry picked from commit 5c91b855b8)
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.
(cherry picked from commit 40c8d2fc2b)
* 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
(cherry picked from commit 20a37e43bb)
* 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
(cherry picked from commit 6b79d7a6a4)
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.
(cherry picked from commit 74be3c3bba)
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.
(cherry picked from commit b6fccfb0f7)
