The work in the 0.5.5 release was focused on bug fixes, but there were a couple small features implemented as well. Overall, I think this cadence of a feature-focused month followed by a bug-fix month makes sense for the project - it gives some flexibility to fix some critical features, even if they aren't called out on our timeline.
Format-on-Save
An oft-requested feature was format on save - implemented in 0.5.5 is an "editor.formatOnSave" configuration setting:
In addition, a pre-requisite for this feature was fixing several blockers in our format pipeline - so several formatting bugs were fixed:
#2196, #2820 - duplication of text after formatting
#3233 - Fix buffer desync when applying formtting edits
With these fixes, completion works better across all languages. A popular extension as well, in the Vim community, is TabNine, and with the above fixes, TabNine now works well in Onivim:
Windows bug fixes
For Windows users, there were several painful bugs that hurt the experience - so part of the 0.5.5 work was geared towards unblocking these issues.
In particular, configuration and keybindings were hard to customize on Windows, because there was no feedback on save like other platforms. This was fixed for 0.5.5:
The latest stable and nightly builds are available here: Early Access Portal
Special Thanks
I wanted to thank the following people for help during the 0.5.5 milestone:
@amiralies - Caught a severe bug in nightly (#3196) and fixed it (#3197). In addition, he implemented 'Smart Case' in the quick menu: #3259
@andr3h3nriqu3s11r - Implement a clear notification button (#3163
@Jorgee97 and @BorisVSchmid - helped narrow down a file explorer issue on Windows (#3092), which led to it being fixed
Thank you!
What's Next
For 0.5.6, it's back to features - we'll be working on Rename and Code Actions / Quickfix in the editor - taking full advantage of the functionality that the language extensions provided.
Thanks for reading, and thanks for all the help in bringing this vision of "Modal Editing from the Future" closer to a reality.
Snippet support is a feature that has been a long time coming - it's one of the features that originally motivated Onivim.
For my personal workflow, it was difficult to set up seamless snippet support across all platforms. Having an it-just-works experience for snippets
across Windows, Linux, and Mac is an exciting milestone for Onivim 2!
In version 0.5.4, snippets are enabled by default, and Onivim comes with built-in snippets for several languages:
When a snippet is active, Tab and Shift+Tab cycle through the available placeholders.
In addition, many extensions provide additional snippets. I enjoy this set of snippets for Markdown:
From the command palette, there are now options to configure user snippets:
Snippet insertion can be bound to a key, as well:
There's more information about using and configuring snippets in our documentation
Emmet Integration
With snippets enabled - and a few other blocking bugs fixed - Onivim can now leverage the bundled Emmet extension to support basic Emmet expansions:
This is enabled by default for html, css, less, and sass - but we recommend some configuration settings to get the best experience with Emmet.
Visual-block insertion and append fixes
A long-standing issue with Onivim was the lack of visual-block edits - using I and A to edit multiple lines at once.
Coincidentally, a pre-requisite to snippet functionality was having the ability to work with multiple-selection and multiple-insert cursors - basically, a baby step towards full multiple cursor support.
We've leveraged this same functionality to support visual-block edits:
Functionally, this should behave the same as using I and A in Vim in visual-block mode - with the added benefit of visual feedback as you type.
Extension host bug fixes
We've upgraded the extension host to 1.53.0 - keeping Onivim within a month of the VSCode update cadence.
Along with the upgrade, there were several fixes to extensions in this release:
#3007 - Show 'missing dependency' activation error to user
#3016 - Fix memory leak in extension host language features
The latest stable and nightly builds are available here: Early Access Portal
Special Thanks
I wanted to thank the following people for help during the 0.5.4 milestone:
@joseeMDS - Implemented the search.exclude configuration option (#3044)
@marcinokoziej - Discovered a critical input loop bug on nightly builds (#3084)
@riedel - Reported a blocking bug with the menubar items (#3108)
@lukamanitta - Logged a critical bug relating to input timeout (#3125)
Thank you!
What's Next
The 0.5.5 build for April will be bit more boring - less shiny features to show, as the the work has been concentrated around bug fixes and refactoring to prepare for the next round of features. More details to come next month.
Thanks for reading, and thanks for all the help in bringing this vision of "Modal Editing from the Future" closer to a reality.
Time flies - can't believe it's been a month and it's time to release 0.5.3. It's nice to be able to share what's happening more frequently!
What's new in 0.5.3
CodeLens
Onivim now supports rendering inline elements between lines of code - and we use it in Onivim 0.5.3 to implement CodeLens, which is contextual information interspersed with source code.
It's particularly useful for working with ReasonML or OCaml, because those extensions show the type signatures that are being inferred, as you edit:
Having that live type inference for those languages is a tremendous time-saver!
However, there are several other extensions that use CodeLens, too. For example, the bundled JavaScript & TypeScript extensions can show reference counts for functions and classes:
(The TypeScript and JavaScript extensions require setting the "typescript.referencesCodeLens.enabled" and "javascript.referencesCodeLens.enabled" configuration settings to true, respectively).
The C# extension uses CodeLens to show reference counts:
In addition, language extensions like Elm use CodeLens to show reference count, as well as which functions are part of the public interface:
This is a feature that I had always wanted in Onivim v1, but never could get quite right. In Onivim v1, we were constrained to the editor model as a terminal-grid-of-characters -
this makes it quite tricky to bolt-on rendering this interspersed contextual information. However, because Onivim v2 handles the complete
rendering pipeline for the editor surface, and is decoupled from the editor being modeled as a terminal-grid-of-characters, it becomes easier, or at least tractable, to implement.
Even still, there were many challenges with performance, with animation, with aligning the viewport to minimize 'jerk', and CodeLens touches
many other features such as word wrap and scrolling. In particular, our function that maps 'buffer position' (a line and a byte) to 'pixel space' needed to be updated to account for
inline elements like CodeLens taking up space (and be quick to calculate when changed, as occurs when the inline elements animate open).
It's an exciting feature, though, because the infrastructure for these inline elements is fairly general - meaning Onivim can potentially render arbitrary UI in between lines.
I'm looking forward to building on this foundation in the future to implement other features, like an inline diff view, or a keyboard accessible 'peek view' to show references
or slices of code from other buffers, without needing to leave your current buffer. Let me know if you have ideas!
Some users may find this feature distracting, though, so you can turn off CodeLens by setting:
"editor.codeLens":false
in your configuration.
Menu bar
Finally... Onivim has a menu bar on all platforms!
On OSX, we integrate with the native application bar:
And the feature is also available on Windows and Linux, using a custom-rendered menu bar:
It's pretty spartan at the moment... but it provides the infrastructure necessary to add more commands.
The menu bar is on by default, but it can be turned off on Windows and Linux with the following configuration entry:
"window.menuBarVisibility": "hidden"
Thanks to @zbaylin for all the work done to wire up the native OSX APIs to support this feature!
Preview functionality
@fanantoxa has implemented a great feature for mouse users - preview functionality.
Preview mode, which is on-by-default, means that the tab for an editor is re-used when clicking on it via the file explorer (and for other views, like search).
This is helpful for users who explore the workspace with the mouse, as it keeps editor tabs from cluttering up the split until they've settled on the right file to work with.
In 0.5.3, the font weight for Onivim is configurable, courtesy of @marcagba! Another feature that has been a long time coming.
This is controlled by a newly added "editor.fontWeight" setting:
Thanks @marcagba for your magnificent work implementing this!
Additional language servers
Onivim now bundles an HTML language server:
The HTML language server supports diagnostics, codelens, completion, and an outline view.
We've also bundled a JSON language server, which features diagnostics and outline view integration.
Extension host bug fixes
We've upgraded the extension host (from 1.51.0 to 1.52.1) - bringing us up-to-date with the Code extension host. Our goal
is to be within a month of the official extension host, so that we can ensure that extensions stay compatible.
In addition, we've continued to fix blockers around extensions, notably:
#2839, #2990 - Fix signature help staying open in normal mode and extra Escape key press
The latest stable and nightly builds are available here: Early Access Portal
What's Next
For our 0.5.4 (March) build, we're still working towards the 0.6.0 goals on our timeline - in particular, the focus for 0.5.4 is integrating snippet functionality in the editor:
I'll look forward to updating you on the progress there next month.
Thanks for reading, and for helping us towards achieving this goal of "Modal Editing from the Future"! Your help, feedback, and support has been critical in allowing us to progress and push forward.
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.
Some highlights:
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).
UI for :! command output
We now support displaying output via the bang :! ex command:
Word-wrap support
Finally, we support word-wrap:
This can be set via the "editor.wordWrap": true configuration setting, or via :set wrap/:set nowrap.
Auto-update
@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.
Fuzzy-finding improvements
@CrossR also made an impactful change that significantly improves our fuzzy-finding strategy - he built ReasonML / OCaml wrappers around the fzy fuzzy finding library - his wrapper is reason-fzy.
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.
The fzy algorithm is a significant improvement on our previous algorithm - both in matching accuracy and performance.
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:
#2712: Add support for additionalTextEdits (auto-import) for completion provider
Vim fixes
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 cs(})
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.
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
These monthly 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.
