I posted this on https://github.com/macvim-dev/macvim/discussions/1472. Cross-posting to the vim_mac email list since there are a lot of overlap between this list and MacVim users: ------------------------------
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 <https://github.com/macvim-dev/macvim/releases/tag/release-179> 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 <https://groups.google.com/g/vim_mac/c/N11WM090ReE>), 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 <https://github.com/ychin/macvim-download-stats/blob/download-stats/github_release/downloads/release-178.csv> 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 <https://github.com/sponsors/macvim-dev> (#1271 <https://github.com/macvim-dev/macvim/discussions/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 <https://github.com/macvim-dev/macvim/releases/tag/release-178>, 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 <https://github.com/macvim-dev/macvim/issues/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 <https://pavelfatin.com/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 <https://github.com/macvim-dev/macvim/labels/Input>): 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 <https://macvim.org/docs/redirect.html?tag=modifyOtherKeys>". 1. *IPC revamp* (Investigate moving away from DO (Distributed Object) as IPC mechanism #1157 <https://github.com/macvim-dev/macvim/issues/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 <https://github.com/macvim-dev/macvim/issues/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 <https://github.com/macvim-dev/macvim/issues/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 <https://github.com/macvim-dev/macvim/issues/1102>. We could also set up Crowdin integration but I'm not sure MacVim has enough texts to justify the effort. 1. MacNeovim / MacNvim (NeoVim fork? #47 <https://github.com/macvim-dev/macvim/issues/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. -- -- You received this message from the "vim_mac" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_mac" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_mac/CAHTeOx82nhiaO91TnCwc7T94c45rUszSHFMMYPDtmq5jdKcHfw%40mail.gmail.com.
