5 ms·

Neovim is still a lot faster for me. A simple example is always commenting out a block <C-v>10jI#, which takes 5 seconds or so in vim (including 8.0), but is in

Neovim is still a lot faster for me. A simple example is always commenting out a block <C-v>10jI#, which takes 5 seconds or so in vim (including 8.0), but is instant in neovim.

6502nerdface 10y ago
The input sequence would be <C-v>10jI#<ESC> (I've just added escape at the end). I'm guessing the delay you are referring to is the delay imposed by your terminal emulator (not vim) to detect the Escape key at the end that terminates visual block mode. If I'm right, you can quickly press "j" just after you press ESC, which should cancel the ESC-detection delay and cause your comment characters to appear instantly. Edit: there's actually a few things that could be at play, including your terminal emulator, your screen/tmux (which is like another terminal editor, really), and vim's timeoutlen and ttimeoutlen settings.
- philh 10y ago
  I wouldn't expect the terminal emulator or screen/tmux to cause a 5s delay in this situation; and if they did, I'd expect them to cause it in neovim as well as in vim.
  - cyphar 10y ago
    This does happen with neovim too. In fact, I had this issue in neovim even though I hadn't had it in vim. It was a one-line config change in my tmux.conf to fix it though, so no skin off my nose.
- randlet 10y ago
  This is interesting! For me using <ESC> does indeed take a few seconds to complete commenting out the block. However, I have jk mapped to <ESC> and the commenting happens instantly using jk which makes sense in the context of your explanation.
  - hsitz 10y ago
    It is interesting, I just tried pressing 'j' immediately after <esc> and the block prefixing does happen right when I press 'j'. The usual lag is just a second or two for me, though, using Gnome Terminal on Ubuntu. Also, there is no lag at all for me in gvim, even without pressing <esc>j.
- ramblenode 10y ago
  You can also add this to your .vimrc: set noesckeys
  - thomasahle 10y ago
    This worked! Sweet! Maybe neovim just has this as default..
rakhimov 10y ago
I'd recommend https://github.com/tpope/vim-commentary https://github.com/tpope/vim-commentary for commenting out code. Anyway, it's not a good practice.
- hackmiester 10y ago
  What would you recommend for turning off a section of code temporarily?
  - jaymon 10y ago
    You could try a plugin I wrote to quickly comment/uncomment blocks of code: https://github.com/Jaymon/vim-commentify https://github.com/Jaymon/vim-commentify It's a no frills plugin that only does one thing, but it does it pretty well.
  - RBerenguel 10y ago
    Kill region, save, run/compile/read, undo if needed. With undo tree (or if you add commit to the process above) there is no need to comment just one region to turn off something. Optionally, convert the region into a separate function/method and just don't call it while checking.
    - pablasso 10y ago
      You still didn't explained why it wasn't a good practice. This just sounds impractical.
      - ssalazar 10y ago
        Yeah, "not a good practice" (i.e. "the user is wrong" or "why would you want to do that?") is the lazy way of justifying software deficiencies.
        RBerenguel 10y ago
        I use emacs, so deficiencies on how vim handles anything do not mean much to me, actually.

Neovim is still a lot faster for me. A simple example is always commenting out a block <C-v>10jI#, which takes 5 seconds or so in vim (including 8.0), but is instant in neovim.

6502nerdface 10y ago

The input sequence would be <C-v>10jI#<ESC> (I've just added escape at the end). I'm guessing the delay you are referring to is the delay imposed by your terminal emulator (not vim) to detect the Escape key at the end that terminates visual block mode. If I'm right, you can quickly press "j" just after you press ESC, which should cancel the ESC-detection delay and cause your comment characters to appear instantly. Edit: there's actually a few things that could be at play, including your terminal emulator, your screen/tmux (which is like another terminal editor, really), and vim's timeoutlen and ttimeoutlen settings.

philh 10y ago
I wouldn't expect the terminal emulator or screen/tmux to cause a 5s delay in this situation; and if they did, I'd expect them to cause it in neovim as well as in vim.
- cyphar 10y ago
  This does happen with neovim too. In fact, I had this issue in neovim even though I hadn't had it in vim. It was a one-line config change in my tmux.conf to fix it though, so no skin off my nose.
randlet 10y ago
This is interesting! For me using <ESC> does indeed take a few seconds to complete commenting out the block. However, I have jk mapped to <ESC> and the commenting happens instantly using jk which makes sense in the context of your explanation.
- hsitz 10y ago
  It is interesting, I just tried pressing 'j' immediately after <esc> and the block prefixing does happen right when I press 'j'. The usual lag is just a second or two for me, though, using Gnome Terminal on Ubuntu. Also, there is no lag at all for me in gvim, even without pressing <esc>j.
ramblenode 10y ago
You can also add this to your .vimrc: set noesckeys
- thomasahle 10y ago
  This worked! Sweet! Maybe neovim just has this as default..

rakhimov 10y ago

I'd recommend https://github.com/tpope/vim-commentary https://github.com/tpope/vim-commentary for commenting out code. Anyway, it's not a good practice.

hackmiester 10y ago
What would you recommend for turning off a section of code temporarily?
- jaymon 10y ago
  You could try a plugin I wrote to quickly comment/uncomment blocks of code: https://github.com/Jaymon/vim-commentify https://github.com/Jaymon/vim-commentify It's a no frills plugin that only does one thing, but it does it pretty well.
- RBerenguel 10y ago
  Kill region, save, run/compile/read, undo if needed. With undo tree (or if you add commit to the process above) there is no need to comment just one region to turn off something. Optionally, convert the region into a separate function/method and just don't call it while checking.
  - pablasso 10y ago
    You still didn't explained why it wasn't a good practice. This just sounds impractical.
    - ssalazar 10y ago
      Yeah, "not a good practice" (i.e. "the user is wrong" or "why would you want to do that?") is the lazy way of justifying software deficiencies.
      - RBerenguel 10y ago
        I use emacs, so deficiencies on how vim handles anything do not mean much to me, actually.