I've been a happy Neovim user for the past several years. The pace of development, quality of the product, and energy of the community have made it enjoyable to use. Recently, the project has introduced Lua as a first-class citizen in the editor. In places where you may otherwise be forced to wrangle the mess that is VimL (aka Vimscript), you can instead use a saner, faster scripting language.

I initially refrained from making the jump over to Lua as I held the ideal of being able to return to Vim whenever I wanted. With the release of Vim version 8, which doubled down on VimL, I realized my folly. Vim wasn't going to suddenly adopt the good parts of Neovim, nor was that community going to change overnight. With that, I sat down one Saturday to get to porting. After a few weeks of on-and-off experimentation (and exploring both /r/neovim and GitHub to see how other people did things) , I landed on a stable, Lua-first config that's been humming along for several weeks now.

Let's dive in!

Read more…

I love Vim (more specifically, the NeoVim fork). Modal editing as part of my Unix IDE brings an immense amount of productivity and enjoyment to my day-to-day development activities. As such, whenever I take up a new language or framework, I enjoy experimenting with how best to integrate it into my existing workflow.

Having started programming in Elixir, I've started the customization journey for the language. Much as with Maslow's Hierarchy of Needs, there's a hierarchy of editor support required for an fulfilling programming experience. Let's get there with Elixir!

Read more…

2016-11-03 Update: Now using the XDG-compliant configuration location.

Now that my initial NeoVim configuration is in place, I'm ready to get to work, right? Well, almost. In my excitement to make the leap from one editor to another, I neglected a portion of my attempt to keep Vim and NeoVim isolated - the local runtimepath (usually ~/.vim).

"But Aru, if NeoVim is basically Vim, shouldn't they be able to share the directory?" Usually, yes. But I anticipate, as I start to experiment with some of the new features and functionality of NeoVim, I might add plugins that I want to keep isolated from my Vim instance.

I'd like Vim to use ~/.vim and NeoVim to use ~/.config/nvim. Accomplishing this is simple - I must first detect whether or not I'm running NeoVim and base the root path on the outcome of that test:

if has('nvim')
    let s:editor_root=expand("~/.config/nvim")
else
    let s:editor_root=expand("~/.vim")
endif

With the root directory in a variable named editor_root, all that's left is a straightforward find and replace to convert all rtp references to the new syntax.

e.g. let &rtp = &rtp . ',.vim/bundle/vundle/' → let &rtp = &rtp . ',' . s:editor_root . '/bundle/vundle/'

With those replacements out of the way, things almost worked. Almost.

I use Vundle. I think it's pretty rad. My vimrc file is configured to automatically install it and download all of the defined plugins in the event of a fresh installation. The first time I launched NeoVim with the above changes didn't result in a fresh install - it was still reading the ~/.vim directory's plugins.

Perplexed, I dove into the Vundle code. Sure enough, it appears to default to installing plugins to $HOME/.vim if a directory isn't passed in to the script initialization function. It appears that I was reliant on this default behavior. Thankfully, this was easily solved by passing in my own bundle path:

call vundle#rc(s:editor_root . '/bundle')

And with that, my Vim and NeoVim instances were fully isolated.

2016-11-03 Update: Now using the XDG-compliant configuration location.

NeoVim is all the rage these days, and I can't help but be similarly enthused. Unlike other editors, which have varying degrees of crappiness with their Vim emulation, NeoVim is Vim.

If it's Vim, why bother switching? Much like all squares are rectangles, but not all rectangles are squares, NeoVim has a different set of aspirations and features. While vanilla Vim has the (noble and important) goal of supporting all possible platforms, that legacy has seemingly held it back from eliminating warts and adding new features. That's both a good thing and a bad thing. Good because it's stable, bad because it can lead to stagnation. A Vim contributor, annoyed with how the project was seemingly hamstrung by this legacy (with its accompanying byzantine code structure, project structure, and conventions), decided to take matters into his hands and fork the editor.

The name of the fork? NeoVim.

It brings quite a lot to the table, and deserves a blog post or two in its own right. I'll leave the diffing as an exercise to the reader. I plan on writing about some of those differences as I do more with the fork's unique features.

Read more…