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, 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