vim-which-key icon indicating copy to clipboard operation
vim-which-key copied to clipboard

bufnext is laggy

Open gbrlsnchs opened this issue 4 years ago • 0 comments

Environment (please complete the following information):

  • OS: Void Linux (kernel 5.7)

  • Neovim version: 0.5.0 (nightly)

  • vim-which-key version: 4e5bd491badecfcd3ecbe0f813d3b31625a8eb4f
  • Have you reproduced with a minimal vimrc: yes

Describe the bug When choosing a mapping with bnext as the command, there's a delay before going to the correct buffer. It seems the floating window is picked by the command and after a timeout, the correct buffer is chosen.

To Reproduce Steps to reproduce the behavior:

  1. Create the minimal vimrc min.vim:
set nocompatible
set runtimepath^=/path/to/vim-which-key
syntax on
filetype plugin indent on

let mapleader = "\<Space>"
let g:which_key_map =  {
      \ 'b': {
      \   'name': '+buffer',
      \   'n': ['bnext', 'next-buffer'],
      \  }
      \ }
call which_key#register('<Space>', "g:which_key_map")
nnoremap <silent> <Leader> :WhichKey '<Space>'<CR>
  1. Start (neo)vim with command: vim -u min.vim

  2. Type Space then b then n

  3. Notice that it's laggy to switch to next buffer because the floating window itself is being selected before going to the next buffer.

Expected behavior Change to the next buffer immediately, not the floating window and then the correct buffer.

Additional context This doesn't happen with bprevious, only with bnext.

gbrlsnchs avatar Jul 30 '20 17:07 gbrlsnchs