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

[johnnyutahh]

[Disclaimer: I hope my somewhat-ignorant "wandering" below is in some way helpful.]

3 years ago I tried the Neovim-based GUIs (I think?), and they did not work for me, so I stuck with MacVim. Hence: I do NOT (yet) consider the Neovim-based GUIs to offer any plausible option to MacVim. (Hopefully @ychin this helps address at least one of your questions?)

Details:

https://www.reddit.com/r/neovim/comments/f6ix6w/a_seasoned_vivimmacvim_user_struggles_with_neovim

What has changed since then to potentially make a move better? I do not know. I have not since re-tried (to move from MacVim to a Neovim-based GUI). It's been all MacVim for me.

More points and questions…

[Apologies if I did not address all of @ychin's above points/questions/details appropriately -- pls let me know if I did not]

I value MacVim tremendously; where can I contribute? I'm a massive fan of MacVim. Thank you thank you @ychin for making and supporting it over the years, decades. It enabled me to avoid adopting/adapting any VSCode-like IDE as a primary/necessary swdev tool, which would have been painful. (An aside, to this end: is https://opencollective.com/macvim/contribute the best place to monetarily contribute? I'm long overdue to do so.)

1 core platform better than 2? (granted: this may not be a novel "take") As an experienced, long-time vi/Vim and multi-platform (macOS, Linux, Unix, Windows) user for multiple decades, I like the idea of "merging" the somewhat-divergent world that seems to be "Vim classic" and "Neovim" based (I guess…?) if for no other reason that managing 1-vs-2 configurations (2 = MacVim/Vim and Neovim-ish stuff) is easier for my user environment, future scaling, etc. (Maybe this point is obvious to everyone?)

Please keep in mind: I'm ignorant of what Neovim can specifically offer, beyond…

Neovim seems like "the future"... I guess? It seems like Neovim might (?) hold long-term momentum to be the vi "core" choice for the longer-term future. (Maybe?) And this may be the primary, if only, reason why I was 3-yrs-ago-investigating Neovim-based stuff/GUIs/etc. (Pls note: I'm a big cmdline user in addition to the GUIs.)

An aside: if someone can help provide context/background for the above, "is Neovim the future" perspective, I'd truly appreciate it.

More points follow. I realize that if these questions are too "uninformed" for this community, it may not be worth taking the time to answer them:

1. @ychin's motivation for Neovim integration seems to be: it's the easiest way to introduce the next design/features (in this case: for IPC, if I'm reading from @ychin's above post correctly?)
2. any additional motivations?
3. can you (@ychin) outline or highlight, to some degree, what might be lost in the "lack of feature parity" for initial MacVim-to-Neovim port/fork/whatever?
4. can someone describe the high-level differences between Vim and Neovim?
5. can someone outline/highlight how MacVim is currently designed? eg: Vim "core" with a macOS-only GUI?
6. will a MacVim-with-Neovim fork (?) require supporting 2 "vim cores" (Vim and Neovim)... or would the plan be to stop Vim one day and start Neovim the next?
7. @ychin writes: "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." → this obviously seems like a good idea, regardless of what happens.

[ychin]

I value MacVim tremendously; where can I contribute? I'm a massive fan of MacVim. Thank you thank you @ychin for making and supporting it over the years, decades. It enabled me to avoid adopting/adapting any VSCode-like IDE as a primary/necessary swdev tool, which would have been painful. (An aside, to this end: is https://opencollective.com/macvim/contribute the best place to monetarily contribute? I'm long overdue to do so.)

Thanks! I do have to point out that I have been maintainer since 2018. Björn Winckler was the original author of MacVim and there were a couple maintainers in between us. Both https://github.com/sponsors/macvim-dev and https://opencollective.com/macvim will work for me, so pick whatever works.

• @ychin's motivation for Neovim integration seems to be: it's the easiest way to introduce the next design/features (in this case: for IPC, if I'm reading from @ychin's above post correctly?)

• any additional motivations?

Well, yes, the biggest difference between how MacVim talks to Vim and a normal Neovim GUI talks to nvim is the IPC mechanism. Now, I don't really want to use msgpack (what Neovim uses) for how MacVim talks to Vim, and will likely use Apple's XPC, but it's just a good time to revisit this topic as I could design the system to be a little more IPC-system agnostic (note that XPC and a stream-based msgpack communication system are still quite different as underlying technology). I have also taken a look at different Neovim GUIs and the API before (for references) and it seemed doable in the long run.

Otherwise it's just that Neovim is a popular alternative to Vim and I'm not opposed to bringing a macOS-native GUI to it. I have used a few Neovim GUIs before and I think very few of them are really developed natively on a macOS and don't really pass the first bars of what I consider to be macOS-native in terms of feel and integration. Otherwise it's mostly an intellectual curiosity and therefore I want to justify with a need first.

Edit: I guess another reason why I'm interested in this is the potential to serve a GUI over a remote SSH connection. I think this is one of the limits of GUI Vim in that you are stuck editing local files, and it's easier to connect to a remote Neovim server than a Vim-based one as a GUI.

can you (@ychin) outline or highlight, to some degree, what might be lost in the "lack of feature parity" for initial MacVim-to-Neovim port/fork/whatever?

It's hard to give a full list. Some MacVim-specific features include: trackpad gesture mapping, scroll bars, autocmd for dark mode. Vim-specific features: :gui / :hardcopy command. Some builtin MacVim commands like autocmd for dark modes. A lot of these can be implemented via other ways but will take some work. Basically, assume that in a lot of ways it won't be better than a smart terminal in the beginning just to get things started.

There are things that I don't know until I investigate.

can someone describe the high-level differences between Vim and Neovim?

This is a long topic and I recommend you just Google it. I'm saying this because if you don't know the difference then maybe it doesn't really matter to you :). Also, this topic has been debated ad nauseam in a lot of venues already. One key aspect is that Neovim is designed to be embedded in a UI rather than comes with it own GUI implementation. This both makes it easy to embed, and make it hard to get certain features "out of the box".

can someone outline/highlight how MacVim is currently designed? eg: Vim "core" with a macOS-only GUI?

MacVim runs a forked version of Vim with custom modification (to support a macOS GUI and unique features like trackpad gestures). The actual app has a single top-level MacVim app process that hosts and talk to the Vim processes inside (each macOS window is a separate Vim process). This is similar to how a lot of Neovim GUIs work, except that most of them run unmodified Neovim instances and just launch it using --headless or --embed flags.

will a MacVim-with-Neovim fork (?) require supporting 2 "vim cores" (Vim and Neovim)... or would the plan be to stop Vim one day and start Neovim the next?

No, we won't be dropping Vim. This will require shipping two apps, MacVim and the new "MacNvim" (or "MacNeovim"? Naming trademark issues?). MacVim will be Vim-first, and Neovim-second (if Neovim support is added) in any foreseeable future that I can see, unless the user count for MacVim has dropped to such a small amount I can count with one hand. The way I can see it happens is if Neovim support is added, and user count seems promising, then there could be more work done to make it better, re-implement certain missing features, and potentially add unique Neovim features (that take advantage of externalized UI), and potentially loop in more developers to help focus on just Neovim support (which I don't think would be hard). If I somehow decide to switch to maintain a Neovim fork full time I will find a maintainer replacement for MacVim first.

[justinmk]

I may also need to fork Neovim for some of the MacVim work

fwiw, Neovim would certainly be open to PRs that help here, to avoid the need to fork. Or just raising a feature request may lead to useful insights.

[johnnyutahh]

Thank you @ychin for your thorough reply, it's much appreciated.

After doing some minimal research, it's likely I will be using, possibly even switching to, Neovim in the not-distant future. Features like Neovim's LSP (eg: https://rsdlt.github.io/posts/rust-nvim-ide-guide-walkthrough-development-debug/) offer tremendous value. When I do, I'll be (re)testing the Neovim macOS GUIs, and I'll update here how much said GUIs are lacking (from my initial experience, at least) compared to MacVim.

An aside, and a point of note in my research: Neovim is "the biggest love" for SO's 2022 IDE survey. These SO developer surveys have served me well in the past, and I'm further motivated because of this result to explore Neovim.

[johnnyutahh]

After doing some minimal research, it's likely I will be using, possibly even switching to, Neovim in the not-distant future.

I'll also be looking into https://helix-editor.com (which is probably no surprise to some):

1. Excerpt from Helix.com: "If Neovim is the modern Vim, then Helix is post-modern."
2. Helix FAQ: Is a Vi/Vim keymap planned?

Helix seems like a signifcant departure from Vim/Neovim. I suspect it's "unthinkable" to consider a MacVim-Helix integration... but I'm massively and ignorantly guessing. I suspect many people here have far more understanding of this than I currently do.

Regardless, it's possibly/probably loved by the Rust-programming community, as it was built on Rust. This further motivates me as my projects are embracing Rust.

[ychin]

Helix seems like a signifcant departure from Vim/Neovim. I suspect it's "unthinkable" to consider a MacVim-Helix integration... but I'm massively and ignorantly guessing. I suspect many people here have far more understanding of this than I currently do.

No, even porting MacVim to Neovim is going to be a lot of work and something that I can't promise, so MacHelix is probably not something I have in mind (doesn't seem like they have a proper API for it anyway). Someone can of course fork the code if they so wish, but I think they should just take the code as reference as write a new project from scratch (MacVim is quite old with a lot of curious hacks just to get it working in the early days and not the best code base to start off with for a new project).

[pusewicz]

Oh man, I was about to create an issue about this. It would be fantastic if MacVim supported NeoVim. Lack of a polished, Mac-like UI is the only thing holding me back from the switch. VimR, while a great attempt, simply does not cut it.

[herrbischoff]

Interesting to see activity regarding Neovim after 8 years. I'm still all for it.

After adjusting to the Lua config environment, I absolutely don't want to go back to VimL. Treesitter support is another big one. Plus, sane defaults for a new century, as opposed to being anchored in 1989. Both approaches have merit of course. Personally, I don't need Amiga and AIX support any more.

I recently took stock of the state of Neovim GUIs (blog post in progress) and the result is sobering. The only one worth considering in my opinion is Neovide, a Rust implementation with minimal cruft. It has repeated major issues starting up at all though. A MacVim-quality GUI is still sorely needed, whichever form it may take in the end.

[swburk]

I switched full-time to Neovim about a year ago, enticed by built-in LSP support. I mostly use Neovim in the terminal because none of the existing GUIs are close to MacVim's level of simplicity and polish. I still use MacVim and maintain my Vim config strictly because it's often convenient to have my editor as a separate app I can quit, hide, and CMD + Tab to rather than getting lost in my sea of other terminal windows.

I don't think I have much to add to this conversation technically, but I would be ELATED if MacVim added support for Neovim. I simply wanted to post to cast my vote in favor of this.