Macvim: NeoVim fork?

[herrbischoff]

Would you consider creating a fork of MacVim based on the NeoVim project instead of Vim? I believe that this is the future of Vim development and would love to see a more performant, more modern implementation of Vim come to life MacVim-style.

[eaoliver]

Just out of curiosity, why is it the future of Vim development?

[ChrisHonniball]

Is it ready to download and run now with all the features?
No. Although some features are a work in progress, Neovim isn't at a stable point. Using Neovim should be done with caution as things may change.

When will a beta be available?
When it's ready.

_- from neovim.io_

Until these items change I wouldn't change MacVim to this. I would however keep up with vim updates better as in #46.

[herrbischoff]

@eaoliver: To not repeat what others have said already (and better than I could), here are a couple of links to better illustrate my opinion. Emphasis is on _opinion_, as obviously there is never an absolute wrong or right. Ideally, I'd just like to kick off a discussion about it.

• http://geoff.greer.fm/2015/01/15/why-neovim-is-better-than-vim/
• https://github.com/neovim/neovim/wiki/Introduction
• http://vimcasts.org/blog/2014/03/support-neovim/

@ChrisHonniball Fair enough. As the original Vim is obviously not going anywhere, a lightweight fork of MacVim for NeoVim is what I had in mind, especially due to its way to connect to a GUI is quite different from original Vim:

Neovim ------> GUI 1 (attach/detach to running instance)
  |  |
  |   `------> GUI 2 (communicating on a different socket or transport 
  |                   mechanism, but sharing the same session with GUI 1)
   `--> Plugin 1
  |
   `--> Plugin 2
  |
   `--> Plugin 3

[cserb]

@herrbischoff I just found this https://github.com/rogual/neovim-dot-app

[herrbischoff]

@cserb Thanks, but the performance of that GUI is unfortunately abysmal.

[RichardDooling]

You can supposedly get "true colors" with the testing builds of iTerm using NeoVim but to me the colors still look weird. If I knew more I'd probably know why. Also scrolling always seems jerky to me running Vim in terminal or experimenting with NeoVim in terminal. So for now I like MacVim. I haven't messed with tmux, which looks like another fascinating distraction.

[justinmk]

It doesn't really make sense to fork MacVim, I don't think, unless there's a significant amount of code that would be worth re-using. If https://github.com/rogual/neovim-dot-app is slow, it's because it's very new and probably not at all optimized. Lots of low-hanging fruit, and forking MacVim would have to deal with those same issues anyways.

[mudox]

Neovim's idea about its UI clients -- Neovim Smart UI Protocol
I think it's better to wait until this low level architecture is built up.

The advantages of this scheme may not be obvious, so let me list a few here:

• Embedders have complete freedom of how windows are displayed (custom decorators, floating windows…) -- Say goodbye to GVim's fake windows ...
• Frameless, single-line windows can be created, good for using Neovim as shell line editor for example.
• Windows can have different fonts/sizes.
• Custom widgets for displaying the command-line and insert-mode completion.

[splhack]

https://github.com/rogual/neovim-dot-app

[johnnyutahh]

Any recent thoughts on this topic (porting MacVim to a Neovim "core")?

[ychin]

This probably will not happen in foreseeable future. It's a pretty significant amount of work to port MacVim to Neovim, in particular because there are a lot of modifications to Vim source code to allow for MacVim to happen. Porting to Neovim means redoing all those work and maintaining a cross-compatible code base. While Neovim is more designed for plugins and therefore should require less intrusive code forking, it still means we have to write another layer to talk to it, not to mention certain MacVim features likely still require code modifications on Neovim.

Long story short, unless I see a compelling reason to, or someone works on it with a solid architecture to maintain compatibility with existing MacVim implementation, it's very unlikely to happen.