Hacker News new | ask | show | jobs
by vegabook 3573 days ago
this async thing was Neovim's main selling point, right? I mean cruft-removal is all well and good but vim works fast and fine for me so not important. What does Neovim now offer that this doesn't?
6 comments

Vim was in a virtual lock down of maintenance mode before Neovim came along and offered some competition. I'm happy to see Vim woken up out of its slumber, but let us not dismiss what Neovim offers or has already accomplished.
The release history: https://en.wikipedia.org/wiki/Vim_(text_editor) doesn't looks pretty active to me.
Edit - I mean does look pretty active.
I think neovim just offered us VIM 8.0.
To be fair VIM developers have said they were all in the mix and coming. We even had Vim plug ins that pulled this off. So I really am not surprised.
'transform Vim into an embeddable text editor engine'

I think that was the main objective of the project. Would be nice to real vim in IntelliJ idea.

As a naive IntelliJ user, I found myself editing files with Vim in IntelliJ's terminal console.
I was amazed when I discovered the console and everything works. I can launch vim, neovim and tig(nurses git front-end) from within IntelliJ and all shortcuts just work. Even fish shell in vi mode or tmux. So yeah, I have the shell running in IntelliJ with tmux enabled and launch tig inside of it.
whoa! had no idea this was thing .
This. And the scripting language I suppose?
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.
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.

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.
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.
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.
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.
You can also add this to your .vimrc:

  set noesckeys
This worked! Sweet! Maybe neovim just has this as default..
I'd recommend https://github.com/tpope/vim-commentary for commenting out code. Anyway, it's not a good practice.
What would you recommend for turning off a section of code temporarily?
For C:

    #if 0
    ...code...
    #endif
You could try a plugin I wrote to quickly comment/uncomment blocks of code:

https://github.com/Jaymon/vim-commentify

It's a no frills plugin that only does one thing, but it does it pretty well.

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.

You still didn't explained why it wasn't a good practice. This just sounds impractical.
Commented code (as in, working code commented out, not comments in code) eventually rots/becomes cruft that at some point in time is going to bite you (or someone else in your team, or some maintainer in the future)
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.
I believe it has a complete embedded terminal
I've actually started using neovim as a default terminal paired with my standard shell. I personally never got that used to the commands for tmux or screen, and with neovim I get the exact commands I am expected as well as -send line to REPL- with https://github.com/kassio/neoterm
having lua as the native scripting language is pretty big too
Lula would be proud ;-)