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.
So, what did I need to do to switch to NeoVim? I installed it. On Kubuntu, all I needed to do was add a PPA and install the
neovim package (and its Python bindings for full plugin support).
$ sudo add-apt-repository -y ppa:neovim-ppa/unstable $ sudo apt-get update && sudo apt-get install -y neovim $ pip install --user neovim
Next up, configuration - one of Vim's great strengths. I dutifully keep a copy of my vimrc file on GitHub, and deploy it to any workstation I use for prolonged periods of time. It'd be nice if I could carry it over to NeoVim.
Suprise! It Just Works™. Remember, NeoVim is Vim, as such it shares the same configuration syntax. Since I don't think I'm doing anything too crazy in my vimrc, it should be a drop-in operation.
After that, it's a simple matter of invoking
nvim from the command line. Everything loaded and worked for me from the first run!
This pleasant detour over, I went to resume lolologist development. However, when I activated my virtual environment and fired up
nvim, I got a message stating:
No neovim module found for Python 2.7.8. Try installing it with 'pip install neovim' or see ':help nvim-python'.
Hm. That's strange. The relevant help docs, however, tell us all we need to know - the Python plugin needs to be discoverable in our path, and, since I'm using a virtual environment, a different Python instance is being used. This is easily addressed, as detailed in that help doc. However, since I use this vimrc file on two platforms (Linux & OS X), I need to be a little smarter about hardcoding paths to Python executables. I added this to my vimrc (it shouldn't negatively impact my Vim use, so it's fine to be in a shared configuration).
if has("unix") let s:uname = system("uname") let g:python_host_prog='/usr/bin/python' if s:uname == "Darwin\n" let g:python_host_prog='/usr/local/bin/python' # found via `which python` endif endif
Restarting NeoVim with that configuration block in place let it find my system Python and all associated plugins.
I'll keep this site updated with any new discoveries and NeoVim experiments! I'm quite eager to see how the client-server integrations flesh out.
I've written more on this! Part 2.
So, I've been working on a tool that turns your commit messages into image macros, named Lolologist. This was a great learning exercise because it gave me insight into things I haven't encountered before - namely:
- Packaging python modules
- Hooking into Git events
- Using PIL (through Pillow) to manipulate images and text
- Accessing a webcam through Python on *nix-like platforms
I might talk to the first three at a later point, but the latter was the most interesting to me as someone who enjoys finding weird solutions to nontrivial problems.
Perusing the internet results in two third-party tools for "python webcam linux": Pygame & OpenCV. Great! Only problem is these come in at 10MB and 92MB respectively. Wanting to keep the package light and free of unnecessary dependencies, I set out to find a simpler solution...
So it seems as if the most recent updates to Kubuntu 12.10 have resulted in a stable graphics experience on my NVidia optimus chipset. As a result, I can now live in penguin land 24/7.
However, transitioning from a fully Lenovo-supported OS (Windows) to a "we'll allow it" OS (Linux) presents it's own set of issues. One can mostly muddle through with enough Google-fu, but one thing that has always vexed me is configuring my TrackPoint (the "red eraser" that TPs are infamous for). The default pointer calibration settings exposed by KDE's system settings are pretty minimal - only allowing me to configure a handful of settings that would apply to both the TrackPoint as well as the touchpad. Not very fun. I set about digging, and found something that worked for my ThinkPad T530:
sudo apt-get install sysfsutils
Then, enter a root shell:
Observe the values of the two settings we care about:
To alter your TrackPoint's speed,
Possible values fall within the the range of 0 - 255, inclusive. Since the results are immediate, you can use trial and error to find a suitable speed.
To alter your TrackPoint's sensitivity,
Possible values fall within the the range of 0 - 255, inclusive. Since the results are immediate, you can use trial and error to find a suitable sensitivity.
Once you've settled on the appropriate values, you'll need to make things permanent. Open your rc.local file and insert the following lines before the "exit 0" return statement:
echo -n 160 > /sys/devices/platform/i8042/serio1/serio2/sensitivity echo -n 110 > /sys/devices/platform/i8042/serio1/serio2/speed
Be sure to replace my values with the ones you deduced in the previous two steps.
And that should do it! There's a graphical tool for managing this, called configure_trackpoint, but it has a whole bunch of Gnome dependences. shudders