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.

[ychin]

So I'm in the process of revamping our IPC (Inter-process Communication) structures (MacVim is using an old deprecated tech called Distributed Objects), and been investigating options to move away from it (#1157). It's very likely that I will end up using Apple's XPC (MacVim's goal has always been to integrate as much as possible using Apple built-in APIs rather than generic third-party dependencies), but it does raise the prospect of refactoring the IPC to be less interdependent, just as a general good software engineering practice. The current IPC system was put together in kind of an ad-hoc fashion over the years and deserve some love to make it more maintainable.

Because of that, I'm revisiting potentially supporting Neovim. Given that Neovim already natively supports a multi-process embedding model, the work of supporting Neovim will be significantly less than the initial work on MacVim (which involved writing its own inter-process communication pipelines). We could treat the msgpack UI as another pipe with similar APIs as the one MacVim has for talking to Vim (they are similar because, well, Neovim evolved from Vim). I also think there are enough sharable features (I mean, both are basically Vim-like so to speak with similar requirements) that it makes some sense to share code.

---

Now, just a general question for people on this thread though: Is such a project/fork/work still appreciated or wanted? There are now lots of Neovim GUIs, including Mac-specific ones like VimR, or cross-platform ones like Neovim-Qt or Neovide. I just want to gauge general interests before I start spending too much time on it, as even though I said "less work", it is very very far from "no work".

The other thing is: MacVim relies extensively on upstream modification to achieve certain features, e.g. mapping <SwipeLeft> on trackpad to a command in Vim. Certain MacVim features like scroll bars also come for free from Vim and in Neovim it's more a "fend for yourself" model where the UI has to implement the logic themselves. So even if I get something working, for a while you won't get some of the features from MacVim today and there won't be feature parity. I may also need to fork Neovim for some of the MacVim work so I'm not sure if it will be able to just plug in to a generic Neovim instance.

I can at least guarantee that the app will be signed and notarized and works like a native Mac app :)

---

Note that this is just a thought for now and gauging interests, and not a promise to work on it. My primary responsibility is MacVim so that would be what takes most of my time and it wouldn't be fair to existing users if I drop off just to add a feature that they are not interested in. This is mostly an intellectual curiosity for me right now. For now I will probably just try to structure MacVim in a way that makes less assumptions of the backend (which is a good idea in general), just to leave the door open for later.

There are also enough differences between Vim and Neovim (in feature set and internal APIs) that will make this not as straightforward as I claimed above. It will kind of double my work in staying up-to-date with upstream changes (I currently read every Vim commit and having to do that with Neovim would be annoying lol). Maintainence will also be a bit painful with maintaining essentially two versions of the same app with two separate upstream to track.

Anyway comments are welcome. I will likely keep using Vim in the foreseeable future myself but I know Neovim is a popular alternative for some and I'm not philosophically opposed to a Neovim port (if it doesn't derail me from maintaining MacVim).