Happy New Year! I hope everyone's 2021 is off to a great start, and you're all staying safe and healthy. Sure was a wild ride, I hope 2021 is a better year...
I want to start by thanking everyone who's helped us weather 2020 and continue to work and progress on Onivim 2. Wouldn't be here without all your support!
So without further ado - I'm pleased to announce our 0.5.2 release. I'll also include some highlights from the 0.5.1 release, which was ninja-released in December and didn't get a formal announcement.
Vim-style navigation across panes
Onivim now supports Vim-style navigation for several UI elements, including the file explorer:
The search sidebar:
And our new symbol outline view (accessible via
gO in normal mode, when provided by a language extension):
All of these can be navigated via the <C-w>h/j/k/l bindings and support many navigation and scroll commands (gg, G, zz, zb, zt, etc).
:! command output
We now support displaying output via the bang
:! ex command:
Finally, we support word-wrap:
This can be set via the
"editor.wordWrap": true configuration setting, or via
@zbaylin has done some heroic work to add auto-update support on Windows and OSX via the Sparkle Framework.
It's so cool to have the infrastructure for this in place, and to have it integrated on Windows and OSX!
Still working on the Linux plan - I'm investigating some strategies - for example, using AppImageUpdate or the Snap store to provide automatic updates. If you have experience, ideas, or preferences here - let me know.
In Onivim, we use fuzzy-finding in our QuickOpen (Control+P, Command+P) mennu, our Command Palette (Control+Shift+P, Command+Shift+P), and for fuzzy matching completion items.
fzy algorithm is a significant improvement on our previous algorithm - both in matching accuracy and performance.
You can read more about this change in the PR: #1566: Integrate Fzy
Previously, we only supported completion when it came from a language extension.
However, 0.5.1 added keyword completion for all file types:
Customizable editor line height
The line height is now customizable, via the
"editor.lineHeight" configuration setting (or, the
:set linespace Vim setting):
Better Windows compatibility with ANGLE
On Windows, it turns out OpenGL isn't that well supported...this is especially true for VMs. The problem is, Onivim relies on OpenGL for rendering.
DirectX tends to receive more investment in terms of driver support than OpenGL. There were several cases where we expected OpenGl to be available, but it just wasn't around (VMs would often have OpenGL 1.0, but we need 3.0+) - this could cause a crash on startup or a blank screen.
Onivim now uses ANGLE, which is an OpenGL API implementation backed by DirectX - this means that we can benefit from better driver, hardware, and platform support, and be more compatible with Windows.
First-run experience on OSX
On OSX, the first-run experience for Onivim was painful - upon starting the editor, you'd be nagged to enable notifications. On top of that, you'd then be prompted for permission to access your Documents - both of these are unnecessary just to start using Onivim, and it's confusing why we'd even ask for these permissions.
We've smoothed these rough edges out, and before, we'd auto-open the Documents folder (resulting in that nag dialog).
Now, Onivim does not open a folder by default:
VSCode Extension Host Fixes
Ongoing, across these monthly releases, I continue to fix bugs and broaden our support for VSCode plugins.
Some notable improvements around the extension host in 0.5.1 & 0.5.2:
- #2332: Add XML extension
- #2422: Upgrade vscode-exthost -> 1.46.0
- #2423: Upgrade vscode-exthost -> 1.47.1
- #2509: Fix blockers for vscode-spell-checker
- #2683: Upgrade vscode-exthost -> 1.50.1
- #2684, #2728, #2786, #2809: Fix various errors around searching / downloading extensions
- #2760: Fix crash on completion details error
- #2712: Add support for additionalTextEdits (auto-import) for completion provider
Of particular note on the Vim-side, I've been starting to do work to unblock
Vim extensions. These expose some bugs in
libvim that I've been addressing.... but we're getting closer to having a plugin like vim-surround working:
(Note that the key display feature doesn't pick up
getchar() right now, due to a bug - but the key sequence I pressed is
This isn't ready for prime-time yet, and still lots of blockers - but the gist is that we are making forward progress here, too.
Other notable fixes:
- #2351: Fix crash on
- #2373: Macro indicator in status bar
- #2364: Show pending operator in status bar
- #2429: Fix visual-in motion (viw/vi") commands
- #2574: Flakiness in cursor positioning after leaving insert mode
- #2699: Implement
getchar()handler (needed for VimL plugin support)
- #2765: Hook up
messages clearex commands
- #2792: Handle count for insert mode commands
This is just a snapshot of the changes in 0.5.2 and 0.5.1. The full changelogs are available here:
One resolution I have for 2021 is more frequent updates - I've had to push deadlines back a few times in 2020 and have had longer gaps between updates - the downside with that is, often, there are smaller changes that would be nice to showcase... but they fall through the cracks. A lot is happening and I'd like to do better in showcasing monthly progress.
Originally, the 0.6.0 release was planned for end of December - so unfortunately I will push it out, as there is still work left to accomplish these renaming goals:
- VimL plugin integration
- Snippet support
- Vim code folding integration
- Code lens
- Code actions
0.5.x releases will be focused on getting us to that milestone.
I'm going to switch the deadline to "When It's Done" - what I found in 2020 was that I'd push aggressive deadlines for myself. I believe these deadline / estimates would be in valid in a vacuum, ie, if I was 100% focused on coding just those features... but, of course, that's simply never the reality.
There's a lot of things that come up in the course of the milestone, perhaps crash reports or daily editor blockers, which I want to address right away, but are unplanned, or opportunistic fixes that get opened up due to contributions or new architecture - the menubar work in 0.5.3 is an example of this.
The other challenge is juggling a variety of priorities that come up:
- Milestone goals
- Daily editor blockers / crashes
- Top upvoted issues
- Vim workstream
- VSCode extension host workstream
So once we get to 0.6.0, subsequent milestones (0.7.0+) will be determined by the highest upvoted issues. This will help to consolidate and stay focused on the right set of priorities for users. You can help me prioritize by upvoting issues that are relevant to you.
Lastly, I've been A/B testing the website - experimenting with Patreon vs the pre-order-lifetime-license. If any patrons would prefer a lifetime license as opposed to a monthly, just send me a message and I'll make sure you're taken care of and get credited the difference.
In the meantime - I'll be continuing to work towards the 0.6.0 release on the timeline - the monthly releases will be
0.5.x until we've accomplished the 0.6.0 goals.
Ultimately, I want to get these features in, stabilize, and get to the point of having a trial build. Onwards :)
Thanks for reading, and for helping us towards achieving this goal of "Modal Editing from the Future"! Your help, feedback, and support has been instrumental in allowing us to progress and push forward.
Cheers, Bryan, Ryan & Zach