Welcome to the first newsletter for Neovim, a project that hopes to give a new beginning to a text editor that we all love.
We asked and the support was overwhelming; the community wanted a newsletter.
The plan is to release a newsletter each month to detail the progress and anything else newsworthy for the project.
Future newsletters will be released on the first Friday of every month. That makes the next one scheduled for July 4th.
Let’s take a look at some of the milestones of the months preceding May:
You may be wondering, “just how much has changed since it forked from Vim?” Well, let’s look at some Git statistics.
Taking into account the initial import of Vim which happened January 31, 2014, there have been 1,010 commits across 77 contributors.
This has resulted in: 887 files changed, 575371 insertions(+), 500868
deletions(-) according to
git diff --stat.
Using a more sophisticated tool such as gitinspector, we can see some more interesting statistics. The entire report of the analysis can be viewed in this Gist.
Now that we have detailed some of the milestones before the month of May started, we can now look at what has happened in the last month.
Neovim has turned on some of the features that were optional in Vim at compile
time. This has led to various
ifdef FEAT_* macros that are no longer needed.
These macros were removed.
Discussion arose regarding Neovim’s inherited crypto code. It was determined that the crypto code should be removed rather than to provide a possibly insecure implementation. The removal was then promptly handled.
Due to name collisions with some of Neovim’s headers, the source code was moved
into a ‘nvim’ namespace. It was also determined that
nvim would be
the internal/technical identifier for the project from that point on.
Vim did have some logging in place but effort was made to create a better
logging utility. The utility uses macros and can log a standard debug
message, basic info, a warning message or an error. The logging can be turned on
or off depending on if
DISABLE_LOG is defined.
There are Vim specific types that are used where standard types would be better options. The complete information regarding these types can be found in this guideline.
long_i types have been removed.
long_u removal is currently underway as well with
types planned for the near future.
Rather than check to see if
malloc returns a
NULL when there isn’t enough
memory for the allocation, a suite of functions were introduced to
handle these out of memory errors.
The functions take care of error handling if this ever were to happen. The removal of the checking for out of memory has spanned many issues (and months) and have been listed in this issue.
The last removal of the memory errors has almost been completed.
A function called
mch_stat() was used to populate a
struct that contained
info about a given filename. The struct contained the
regarding the file.
To increase developer clarity, the code for this was refactored into new
functions defined in
os/fs.c. The existing calls to
were then switched over.
Coverity Scan is a service that performs a static analysis on source code to look for defects and vulnerabilities. It can look at multiple paths through execution and find issues that might only arise under certain conditions.
Neovim now has a Coverity check that runs multiple times a week in addition to the continuous integration that is used with TravisCI.
You can now listen and register for various API events. This is done by using the API channel id when making the request.
In addition to this, a Wiki page has been created to detail the current look at the plugin architecture. As the top warns, not all the features have been implemented but take a look at it to learn more.
The following is a list of things that are either in progress or on the roadmap.
system()and use pipes instead.
There has been some questioning on the motivation for this feature. The
reasoning is that the evaluation of the VimL language is housed in the file
The file currently has 19,164 lines of code. By creating the translator, it would remove the need for this evaluator. Instead the Lua code could rely on the newly developed API that would be properly tested.
When asked in the mailing list about the progress, Thiago detailed the list of things that’s necessary for the first official release:
- Finish implementation of redraw events <- doing this right now
- Use the redraw events to implement a new infrastructure for integration tests based on busted/lua.
- Write a cross-platform GUI program
- Compatibility layer for old python plugins on top of the python client(except for plugins that use python features introduced in 7.4)
- Make it compile/run on windows(I dont think this will be hard since a lot of platform-specific stuff already runs on libuv)
If there’s a volunteer, I’m going to delegate writing the GUI program after I finish implementing redraw events since I’m not very good with designing UIs.
If you’d like to help support development, you may donate using Bitcoins here:
1Evu6wPrzjsjrNPdCYbHy3HT6ry2EzXFyQ or back the team on the Neovim
If you an experienced developer or inexperienced but wanting to learn, visit the GitHub repo and check out the README, CONTRIBUTING guide, and finally the Wiki to learn more.
There are plenty of opportunities to help out and plenty of things to do.
Do you have any feedback or suggestions regarding this first newsletter? Feel free to reach out through the Neovim Twitter.
Also be sure to subscribe to the RSS feed to stay up-to-date on what is happening in the Neovim world. The next newsletter will be released the first Friday of July.
Until next time.
Find more updates in the news archive.
Neovim is a Vim-based text editor engineered for extensibility and usability, to encourage new applications and contributions.
Visit #neovim:matrix.org or #neovim on irc.libera.chat to chat with the team.
RSS clients can follow the RSS feed.