The clean-up is done in s:collect(), so let's make sure it's run before
we may terminate due to CTRL-C or ESC (or some other error code) in
s:exit_handler().
The output may contain some unexpected warning messages from the shell
if it's not properly configured. While such extra messages should be
properly addressed by the user, we can ignore them by checking the
last line of the output instead of the first line.
Related: bd3a021ec1
The new default is
{ 'window' : { 'width': 0.9, 'height': 0.6, 'highlight': 'Normal' } }
The default highlight group for the border of the popup window is
'Comment', but 'Normal' seems to be a safer choice.
If you prefer the previous default, add this to your Vim configuration file:
let g:fzf_layout = { 'down': '40%' }
(fzf will fall back to this if popup window is not supported)
Preserve current directory in case current directory is changed by others
after the call of s:open
Co-authored-by: Junegunn Choi <junegunn.c@gmail.com>
* No need to restore &wfw and &wfh when using popup window
Co-authored-by: lacygoill <lacygoill@lacygoill.me>
Co-authored-by: Junegunn Choi <junegunn.c@gmail.com>
Invoking fzf from an existing Vim popup terminal is a special case.
It requires some new code to avoid E994 from being raised and the user
being stuck in a non-closable popup window.
Fix#1916
Revert the change introduced in #552. It seems that the startup time
difference between bash and fish is not much of an issue now.
> time bash -c 'date'
Thu Feb 13 21:15:03 KST 2020
real 0m0.008s
user 0m0.003s
sys 0m0.003s
> time fish -c 'date'
Thu Feb 13 21:15:05 KST 2020
real 0m0.014s
user 0m0.007s
sys 0m0.006s
When we explicitly *pipe* $FZF_DEFAULT_COMMAND instead of making fzf
internally start the process ($FZF_DEFAULT_COMMAND | fzf), fzf may hang
if the input process doesn't quickly process SIGPIPE and abort.
Also, fzf#vim#grep temporarily swaps $FZF_DEFAULT_COMMAND instead of
setting 'sink' so fzf can kill the default command on 'reload'.
https://github.com/junegunn/fzf.vim/issues/927
However, because of the "pipe conversion", the trick wasn't working as
expected.
467c327788/autoload/fzf/vim.vim (L720-L726)
We can go even further and always set $FZF_DEFAULT_COMMAND instead of
piping source command.
* Add MSYS2 support as a vim plugin
Add &shellcmdflag and TERM environment variable treatment.
- Make &shellcmdflag `/C` when &shell turns into `cmd.exe`
- Delete %TERM% environment variable before fzf execution
* Change shellescape default value depending on s:is_win flag
* Make TERM environment empty only when gui is running
* Stop checking &shell in fzf#shellescape function
This funcion's behavior is controlled by only if it is Windows or not.
So there is no need to check &shell.
* Take neovim into consideration when to set shellcmdflag
* Add &shellxquote control
In recent Nvim versions, an "Error running ..." message is shown even for normal
use cases, such as:
:Files
<c-\><c-n>
:close
Closing the window will :bwipeout! the terminal buffer, because fzf sets
bufhiden=wipe.
When deleting the terminal buffer while fzf is still running, Nvim sends SIGHUP.
This happens for quite some time already, but the bug only manifests since this
commit:
https://github.com/neovim/neovim/commit/939d9053b
It's The Right Thing to do when the application exited due to a signal.
Before that commit, no "Error running ..." message was shown, because 1 (instead
of 128 + 1 == SIGHUP) was returned which the exit handler in fzf.vim treats as
"NO MATCH".
