lambdas and closure .. and vim/neovim split .. almost Emacs ;)

Soon NeoVim will no longer update regularly because Vim has caught up and/or surpassed it with every feature that matters...

By that time Emacs will have replaced temacs with Guile and someone clever will have added VimScript as a hosted language.

It's close, but I think NeoVim's RPC model could be huge. Writing a new frontend for vim no longer seems that crazy of a goal which makes it easier for people to experiment with new editor ideas while relying on the very solid core of vim (well at least I find that exciting, idk if the general vimmer cares).

I dream of the day that when you tick off "vim binding" in the settings of any IDE it loads neovim for controlling the buffer.

Or rather, a day where its easier, more flexible, and more performant for IDEs to always(only) use an embedded neovim. Getting plugin support "for free".

The keybindings would then be the only thing that the IDE changes.

I dream of the day when the IDE is in vim. There has been some great work around c# for this lately, where the compiler is running as a service and vim makes an async call for file completion, etc.

Why stop at the IDE? Why not tick a checkbox in system preferences and it lets you use vim to edit anywhere you can type text.

Now I would pay for that feature decent sum of money :D.

Are you familiar with Wasavi? Vi(m?) for browser text windows, at least.

http://appsweets.net/wasavi/

The neovim project is still a massive undertaking about refactoring such old and non trivial piece of code in what appears to be a smooth way. I hope they can keep working on it, in symbiosis with vim.

I'd love to see vim add an embedded terminal emulator in a window based on the async support. That feature alone motivated me to try neovim.

That is tmux's job. Do one thing well.

I use ConqueTerm, inside vim, a plugin that supplies a terminal inside Vim. If you put the emulator inside the editor, you can take advantage of vim's extremely capable text manipulation. If I tmux then vim, I have to find some way to get the text out of tmux, and then back into vim.

Also, who says vim is running in a terminal?

Living inside the terminal, multiplexing is useful even when not using Vim and I think Tmux is a better multiplexer than Vim. I would need to use Tmux anyway for it's sessions.

I already use Tmux inside a tiling window manager and generally try to avoid manually managing panes inside Vim, mostly only tabs. There is a finite amount of hierarchical panes and tabs you can work with intuitively, before you wonder why they won't accept each others keyboard shortcuts, especially when you use the same color scheme in Vim, Tmux and Awesome.

> If I tmux then vim, I have to find some way to get the text out of tmux, and then back into vim.

That's actually a valid concern. I use piping for that, but it's not ideal at all. Maybe I will try it out.

> There is a finite amount of hierarchical panes and tabs you can work with intuitively, before you wonder why they won't accept each others keyboard shortcuts

Exactly the reason I want to manage terminals in vim. I already heavily use splitting in vim, and find it much faster and simpler to use than screen or tmux. In addition, I typically want integration between those splits, such as displaying the quickfix list in one, or showing 2-3 files in vimdiff, or yanking and pasting between files. Given that, I'd like to just open one more split in vim and have a terminal in it.

The original motivating use case for me: a vertical split, editing a manpage on one side, and showing a continuously updated render of the manpage on the other (using watch).

I was playing devils advocate a bit in the last post ;-) My workflow involves a mix of the two methods. If I know I'm going to be doing text manipulation, I'll use vim+ConqueTerm, but more normally I just let iTerm2's splitting handle it. (I actually prefer it over tmux/screen, but when you need multiple things on a remote, I can see why people prefer it.)

That feels like the realm of a plugin, IMO. (I don't know enough to know whether or not that type of thing could be done via plugin, though.)

With the new async support it should be relatively simple, weekend project simple for a basic implementation.

Depends on how you implement it. neovim's implementation uses libvterm, which seems preferable to a from-scratch terminal implementation. Implementing a fully capable terminal emulator from scratch definitely isn't a weekend project.

neovim's approach links libvterm in via C. You could potentially do so via python and ctypes instead, but then you have to count on having a vim compiled with Python support.

I was thinking I'd just start sh/cmd in a process and use stdin/stdout. The api even allows for automatically sending appended lines to stdin.

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?

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 use emacs, so deficiencies on how vim handles anything do not mean much to me, actually.

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 ;-)

How is Neovim working out for you? I remember using it at one point and it was really smooth experience.

I'm using it every day for a couple of months now, never crashed and loads faster than Vim 7.

Anyway, the things I appreciate more are the fast evolution and the community, no more than one year ago I tried it but was too lazy to compile, wait, configure...

This time I ran homebrew, linked my .vimrc in ~/.config/nvim/init.vim, and forgot I was using Neovim instead of Vim, except for the async compiling/linting.

I switched more than a year ago and have never had stability problems; it's been only performance and feature enhancements for me. The most obvious was that saving my files no longer locked up the interface for a couple seconds while linters ran (thank you async). More subtly, I had to go on a plugin diet initially that slimmed my features down to what I actually used regularly; since then, I judge the quality of plugins to be improved because they're either new plugins by authors excited to code for neovim, or they're current plugins that got a decent overhaul to work with both.

From what I understand, the plugin community is generally pretty happy with neovim and find it preferable.

Not the parent but FWIW I've been using neovim for +6 months now and it's fantastic. I'm super impressed at the pace of progress and responsiveness of the team.

I've since switched all my plugins to use async versions and it's sooo fast, didn't think vim could be faster but here we are.

Could you mention which plugins you switched to? Is there a list somewhere that details the alternatives that work better in neovim?

Off the top of my head:

- vim-plug for a plugin manager (very good regardless of concurrency)

- neomake for building

- vim-go added async job support using neovim a while ago for most of its functionality, which I use for writing Go

My full inventory is here: https://github.com/shazow/dotfiles/blob/master/.vim/plugins....

Do most vim plugins work without changes in neovim? I'm mostly using vim-airline and tagbar to be honest, wouldn't be sad if the other ones stopped working.

VimScript is not deprecated in NeoVim, and maintaining backward compatibility is major focus. So must Vim plugins will work in Neovim. vim-airline is listed among the plugins that has some special neovim-specific features added: https://github.com/neovim/neovim/wiki/Related-projects

Cool, thanks.

I've been using neovim for almost a year now, and have contributed some (small) code fixes and also donate to the project. It works great for me, and I completely forget that I'm using neovim (until I use :terminal). Also, from what I hear, contributing to Vim is much harder than NeoVim so I'm more inclined to contribute to a project which has a healthy community of contributors.

I am stuck at 0.1.3 as I am unable to brew install any of the newer versions. (It craps out on some LuaJIT stuff and I haven't really had time to fight with it) Aside from having to mess with it to get CTRL-h working, it's been pretty smooth. I LOVED vimplug (the package manager) with its async installs. I have high hopes for NeoVim's future... even if that future turns out to be just giving Vim a kick in the pants to move forward.

Try cleaning your Homebrew cache for neovim.

    rm -rf /Library/Caches/Homebrew/neovim--git
    brew reinstall --HEAD neovim

nope, sadly:

    ==> make VERBOSE=1
    Last 15 lines from /Users/jimwharton/Library/Logs/Homebrew/neovim/02.make:
  "__Unwind_GetCFA", referenced from:
      _lj_err_unwind_dwarf in libluajit.a(lj_err.o)
  "__Unwind_RaiseException", referenced from:
      _lj_err_throw in libluajit.a(lj_err.o)
  "__Unwind_SetGR", referenced from:
      _lj_err_unwind_dwarf in libluajit.a(lj_err.o)
  "__Unwind_SetIP", referenced from:
      _lj_err_unwind_dwarf in libluajit.a(lj_err.o)
    ld: symbol(s) not found for architecture x86_64
    clang: error: linker command failed with exit code 1 (use -v to see invocation)
    make[4]: *** [luajit] Error 1
    make[3]: *** [src/luajit] Error 2
    make[2]: *** [build/src/luajit-stamp/luajit-install] Error 2
    make[1]: *** [CMakeFiles/luajit.dir/all] Error 2
    make: *** [all] Error 2

I know I just need to jump into figuring out how to get the ONE version of LuaJIT that works (as I've read, there is only one) and pop that in there.

Try:

    unset LUA_CPATH LUA_PATH
    brew reinstall --HEAD neovim

Really great! It was honestly a relatively painless transition for me.