The heart of the API is vimInput which takes a single key, and is synchronously processed by the state machine. Native builds could be useful for applications that want Vim-native bindings - it'd be a nice foundation for implementing readline, for example.įor an example of the API usage, check out the apitests like normal_mode_motion.WebAssembly builds could be useful for implementing Vim modes in browsers / websites.There are other interesting applications of such an 'abstracted Vim': Libvim builds cross-platform (since Onivim 2 requires it!), as well as for WebAssembly - we'd like to port our v1 tutorials to a browser-based experience. Any sort of UI rendering (terminal, etc)Īll of these are intended to be handled by the consumer of the library - leaving libvim to be focused on the job of fast buffer manipulation.Buffer manipulation in response to input.To that end, libvim exposes a simple C API for working with Vim, and supports listening to buffer changes, messages, etc. As Onivim 2 completely handles the rendering layer, this Vim-modelled-as-a-pure-function could focus on just buffer manipulation. After implementing several iterations of 'UI Vims' between v1, v2, and other projects, the abstraction I wished to have was a sort of a pure functional Vim, completely decoupled from terminal UI - where 'vim' is a function of (editor state, input) => (new editor state). Libvim is primarily intended for Onivim 2. If you're looking for a terminal Vim, check out neovim, or a GUI Vim, check out Onivim 2. It's still a work-in-progress and there is lots of work left to stabilize. It does not include any user interface at all (not even a terminal UI), and is primarily responsible for acting as a fast buffer manipulation engine, faithful to Vim keystrokes. Libvim is a fork of Vim, with the goal of providing a minimal C-based API, modelling Vim modal editing.
0 Comments
Leave a Reply. |