Skip to content
Snippets Groups Projects
This project is mirrored from https://github.com/junegunn/fzf. Pull mirroring failed .
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer or owner.
Last successful update .
  1. Feb 16, 2020
  2. Feb 14, 2020
  3. Feb 13, 2020
    • Junegunn Choi's avatar
      [vim] More border styles · 4fb410a9
      Junegunn Choi authored
      e.g.
      
        let g:fzf_layout = { 'window': { 'width': 0.4, 'height': 1, 'xoffset': 0, 'border': 'right' } }
        let g:fzf_layout = { 'window': { 'width': 0.4, 'height': 1, 'xoffset': 1, 'border': 'left' } }
        let g:fzf_layout = { 'window': { 'width': 1, 'height': 0.5, 'yoffset': 1, 'border': 'top' } }
        let g:fzf_layout = { 'window': { 'width': 1, 'height': 0.5, 'yoffset': 0, 'border': 'bottom' } }
      Unverified
      4fb410a9
    • Junegunn Choi's avatar
      [vim] Do not pipe FZF_DEFAULT_COMMAND · 5e1db9fd
      Junegunn Choi authored
      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.
      
      https://github.com/junegunn/fzf.vim/blob/467c3277884240f7b5430f8f4d600e3415c38f3b/autoload/fzf/vim.vim#L720-L726
      
      We can go even further and always set $FZF_DEFAULT_COMMAND instead of
      piping source command.
      Unverified
      5e1db9fd
  4. Feb 12, 2020
  5. Feb 10, 2020
  6. Feb 06, 2020
  7. Feb 05, 2020
  8. Feb 03, 2020
  9. Jan 07, 2020
  10. Dec 16, 2019
  11. Dec 15, 2019
    • Jan Edmund Lazo's avatar
      [vim] Use cterm colors on Windows (#1793) · aa0e10ea
      Jan Edmund Lazo authored
      Truecolor does not work on default Windows terminal.
      It is a problem in neovim GUIs.
      
      https://github.com/sainnhe/edge/issues/5#issuecomment-565748240
      aa0e10ea
    • msr1k's avatar
      Add MSYS2 support as a vim plugin (#1677) · a9906c7c
      msr1k authored
      * 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
      a9906c7c
  12. Dec 12, 2019
  13. Nov 11, 2019
    • Marco Hinz's avatar
      [nvim] Handle SIGHUP in exit handler (#1749) · 16fc6862
      Marco Hinz authored
      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".
      16fc6862
  14. Nov 02, 2019
  15. Oct 08, 2019
  16. Sep 29, 2019
  17. Sep 09, 2019
  18. Jul 09, 2019
  19. Mar 28, 2019
  20. Mar 26, 2019
  21. Aug 20, 2018
  22. Aug 10, 2018
  23. May 13, 2018
  24. Apr 26, 2018
  25. Jan 26, 2018
  26. Dec 05, 2017
  27. Dec 03, 2017
  28. Nov 22, 2017
  29. Sep 30, 2017
  30. Sep 29, 2017
  31. Sep 07, 2017
  32. Sep 05, 2017
Loading