MacVim 2023 retrospective and roadmap

[ychin]

Happy New Year! I originally wanted to send this out by EOY 2023, but holiday mood struck me and so running a few days late. MacVim r179 is now out, which comes with Vim 9.1 which has also just been released. Given that I became maintainer of MacVim ~5 years ago (see my post then), I thought it's a good time to do a quick retrospective and talk about what to look out for in 2024.

Retrospective

2023

For the past year, in addition to features and bug fixes, I also did some clean up of general things such as having the website properly point to macvim.org, having documentation available on the website, better tracking of download counts for different versions (to help gauge if supporting a legacy version is useful), clearer version naming, and better ways to find out what has changed for those who don't use the binary release's built-in updater (e.g. Homebrew). We are also getting more testing coverage for MacVim, albeit gradually.

On compatibility, MacVim still supports down to macOS 10.9 like before, but because of changes in Apple's developer tools, we now have to build a separate "legacy" binary release for macOS 10.9 - 10.12 users. I don't see an immediate reason for dropping support for these older macOS versions for now, but CI (GitHub Actions) changes could make it harder to support in the future. When I looked at the download counts, the legacy version for r178 has received ~1600 downloads so far, which isn't nothing, so I'll see if we can keep it going through other means when that happens.

MacVim also started to allow sponsors (#1271) for the past 1.5 years! It will obviously continue to be free and open source, but sponsorship does help support the project and cover some expenses and I deeply appreciate the users who like MacVim enough to sponsor the project. Thanks!

Small note about Touch Bar: While I personally liked the Touch Bar and have tried to support it and make it useful within MacVim, it never seemed to catch on within the larger macOS ecosystem. With the release of the M3 MacBook lineup in 2023, Apple has stopped making any computer that has a Touch Bar, meaning that it is essentially a deprecated technology. MacVim will still work with it, but there will likely be no further Touch Bar integration work in the future for MacVim.

Also, as I have mentioned in a previous release note, Bram (creator of Vim) has unfortunately passed away this year. It's a great loss for the Vim community, and I want to thank the current Vim maintainers for stepping up and keeping the project alive.

Maintainership and community involvement

I became the maintainer 5 years ago, and looking through the priorities I listed, I think I'm mostly happy with what was done. However, documentation is still a little lacking, with poorly organized wikis and README; and we still do not have great testing coverage.

The other issue was that the amount of time I had to work on MacVim fluctuated which resulted in occasional breaks in MacVim development. One aspect that I wish I could have handled better is to review/merge pull requests much quicker (there are still a couple outstanding ones right now which I'm not proud of).

In general, MacVim does not see a lot of pull requests or community involvement, which I am trying to understand more. Does that indicate that the project is mostly mature and doesn't need much changes? Or that it mostly serves as a downstream project to Vim and most changes go to Vim itself? Or that the development model makes it hard for contributors to get their feet wet, or submit patches? If it's the latter, please feel free to leave a comment.

Roadmap

Outside of small features and bug fixes, below are some main features of MacVim that I want to work on in 2024. Please note that they may not all get done by 2024 as some of these are a lot of work, but I'm hoping to at least start work on them:

1. GPU-accelerated renderer and latency improvements (Implement Metal renderer for MacVim #1262): Currently MacVim is still rendering texts using a software Core Text renderer. Scrolling through a lot of texts still results in stuttering even on a new Mac. A hardware-accelerated renderer would also allow us to implement other features (e.g. smooth scrolling) as well. Also, from measuring input latency (using Typometer), MacVim's input latency is actually quite high right now and lags behind other text editors, which in my opinion is a little embarrassing for a Vim-based editor. After hardware renderer is implemented I would like to re-measure and proceed to implement various tactics to improve input latency. My hope is to get MacVim to be the text editor with the lowest latency on macOS, but it will likely be a slow grind instead of a single magic bullet.

2. Input (issues): There are various input-related issues with MacVim that I think deserve to be fixed up. This includes better integration with input methods (especially for CJK languages), better ways to map Option keys (instead of needing to set macmeta), and supporting "modifyOtherKeys".

3. IPC revamp (Investigate moving away from DO (Distributed Object) as IPC mechanism #1157): Currently MacVim relies on an old deprecated technology called Distributed Objects to communicate between the MacVim UI and Vim. This has caused issues before, and Apple has deprecated it for years. The current plan is to move to using the newer XPC technology instead. One issue is that we may have to add a background service in order to support the Vim client-server protcol and the :gui command, which may seem a little suspicious to a user, but that probably just needs some education (the service is just there to relay the messages to MacVim, and is unfortunately how XPC works). Alternatively we could do what Neovim does and just open a socket.

Some other things that are interesting to me, but may not be as high importance:

1. Overlay scrollbars ([Feature Request] Automatically show and hide scroll bar #967): Implement macOS-style scrollbars. Lack of such scrollbars has always made MacVim felt not very "Mac-like" to me.

2. Smooth pixel scrolling (Pixel by pixel scroll. #273): This is a feature that's seen in some Neovim GUIs. It's very cool looking, but I would like to implement it correctly (including natural trackpad scrolling), and it likely requires some upstream Vim changes after trying some initial experimentation. I personally think this feature has a lot of value as it helps to prevent disorientation by visually anchoring the text during scrolling.

3. Accessibility: I'm quite unsure about this one. I would like Vim / MacVim to be usable by visually impaired programmers, but the fact that MacVim is currently completely unusable by them means I'm not sure how to get feedbacks on this to start with. Feedbacks are welcome.

4. Localization. Currently MacVim is half localized. If there are volunteers interested in helping filling in the gaps please comment on Epic: Localize MacVim and add translations #1102. We could also set up Crowdin integration but I'm not sure MacVim has enough texts to justify the effort.

5. MacNeovim / MacNvim (NeoVim fork? #47). This is obviously a somewhat contentious idea, but I have been contemplating the feasibility of porting MacVim to work with Neovim as well, as there seems to be some demand for it, and Neovim also has better support for connecting a GUI to a remote source (e.g. via SSH). After the IPC revamp it may be easier to do this. The main issue is this could be a lot of work (both implementation and ongoing support) and I have no plans to drop MacVim itself, so it may only work if the Neovim community helps support it after the initial port. This is quite low on priority for now.

---

This is it! Let me know if this kind of roadmap is useful or not. I'm still debating on the frequency and size for project updates like this as they do take some time to organize and type, but if it's useful I may continue to do this in the future.

[ubaldot]

I just installed the update. What to say? THANK YOU for all the work you guys are doing to make an incredible product.

I also have a fairly clear view opinion about NeoVim porting: as mentioned, there is the eternal problem of available time VS workload, and given that Vim and NeoVim are diverging more and more, I see a high risk that in the future the maintenance effort of both tracks will grow exponentially with consequences that are not difficult to imagine.
Hence, I would rather focus to work only on one track to secure solidity over time (I am not a contributor but a mere user, but I given that you asked I expressed my view :))

[lifepillar]

Thanks for sharing your roadmap!

I second the goal of improving latency. Not so much the idea of MacVim installing a launchd service—but if that's the best way to go, I'd live with that. And I totally agree with @ubaldot regarding Neovim. But I am not a Neovim user, so I have not much interest in such a fork.

I don't have particularly complex input needs (combining characters and phonetics are the most advanced I've had): custom macOS keyboards and Vim's i_CTRL-K are sufficient.

Of the remaining features, accessibility seems the most valuable. Accessibility is hard in many ways, one of them being, as you point out, how to get started: you need feedback from people with accessibility issues, but if MacVim is not accessible, those people won't use it. Maybe, a good starting point would be to add some integration with VoiceOver. That may be challenging, I believe, as Vim's modal approach might clash with VoiceOver's use of the keyboard. Have you explored that possibility already? I would also get inspiration from other editors, such as VS Code.

Finally, thank you also for supporting older macOS releases: I'm really glad that I can still use the latest MacVim in High Sierra!

[ychin]

Not so much the idea of MacVim installing a launchd service—but if that's the best way to go, I'd live with that.

Yes, I understand the hesitation from a user, as I would have had the same reaction myself. At least in recent macOS versions the Settings app now has easy ways to turn it on/off, but I still don't love the idea.

Boring technical details: This is mostly needed for things like :gui, because the Vim process (owned by the terminal shell) needs to connect to a separate GUI process that doesn't own the Vim process, and therefore needing a service to relay it back and forth. Currently, NSConnection just exposes a connection that anyone can connect to (which is kind of insecure tbh) when you open MacVim. We could explore other venues like just making a globally named socket (which also means everyone can connect to it) instead of NSConnection but it would have similar issues. To be fair every Neovim process does kind of do that (see Neovim's v:servername) although their names are at least somewhat randomized.

So I'm still thinking through the options.

Of the remaining features, accessibility seems the most valuable. Accessibility is hard in many ways, one of them being, as you point out, how to get started: you need feedback from people with accessibility issues, but if MacVim is not accessible, those people won't use it. Maybe, a good starting point would be to add some integration with VoiceOver. That may be challenging, I believe, as Vim's modal approach might clash with VoiceOver's use of the keyboard. Have you explored that possibility already? I would also get inspiration from other editors, such as VS Code.

Yes, I have looked at that VS Code web page before. From what I read about it it seems to work fine but I have also read complaints about it not being as good as it could be as well, but it's still better than nothing. Part of the issue is that MacVim is the GUI component of Vim, so more fundamental support will need to be done upstream at Vim first, with each GUI implementing their part, hence it being a more complicated project than just MacVim doing its thing.

But yes, MacVim can implement simple voice over support and it will be the low hanging fruit. In fact, if you use Vim on a regular terminal I believe you get that today. One issue is that as you said, it's kind of a dumb "pronounce what's on screen" mode and doesn't give you more proper insights for things like Normal mode. It's probably "usable" but in a way that most people would rather use something else. I have looked at a couple threads on Reddit before but it's not terribly informative. As I mentioned, poor accessibility = no users = no feedbacks.

[ychin]

combining characters and phonetics are the most advanced I've had

This is the one thing that is hard to do today. If you have macmeta set, you can't use Option key to input characters like "é" (Option-E, e) or "…" (Option-;). It also affects things like Normal mode's f commands, and more. There are just a lot of little things (hence it's a list of issues).

[masukomi]

i want to second the thanks for all the work. Personally i'd love NeoVim support. I see NeoVim as the future path for Vim users.

Full disclaimer: i do most of my work with Doom Emacs but I do open MacVim almost daily.

[antoniopaolini]

Hello, and thank for your great work!

Or that it mostly serves as a downstream project to Vim and most changes go to Vim itself?
I've always thought of macvim as a side-by-side project, a GUI fro Vim. Then I never expected editing improvement from MacVim but I thought that the development was done in Vim, and then MacVim expose the features to us.

I want to highlight that I'm a simple user, not a programmer nor contributor (but I use Vi, end next ViM since about 1993 :-) ).