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 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. 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). 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).
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.īecause of that, I'm revisiting potentially supporting Neovim.
Macvim vs neovim software#
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. 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).
0 kommentar(er)
