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
"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.
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:
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.
This was originally posted to a former employer's blog. It has been mirrored here for posterity.
Here at HumanGeo we do all sorts of interesting things with sentiment analysis and entity resolution. Before you get to have fun with that, though, you need to bring data into the system. One data source we've recently started working with is reddit.
Compared to the walled gardens of Facebook and LinkedIn, reddit's API is as
open as open can be; Everything is
nice and RESTful, rate limits are sane, the developers are open to enhancement
requests, and one can do quite a bit without needing to authenticate. The most
common objects we collect from reddit are submissions (posts) and comments. A
submission can either be a link, or a self post with a text body, and can have
an arbitrary number of comments. Comments contain text, as well as references
to parent nodes (if they're not root nodes in the comment tree). Pulling this
data is as simple as
(Protip: pretty much any view in reddit has a corresponding API endpoint that
can be generated by appending
.json to the URL.)
With little effort a developer could hack together a quick 'n dirty reddit
scraper. However, as additional features appear and collection-breadth grows,
the quick 'n dirty scraper becomes more dirty than quick, and you discover
bugsfeatures that others utilizing the API have already
encountered and possibly addressed. API wrappers help consolidate communal
knowledge and best
practices for the good of all. We considered
several, and, being a
Python shop, settled on PRAW (Python Reddit API
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...
It was your run of the mill work day: I was trying to close out stories from a jam-packed sprint, while QA was doing their best to break things. Our test server was temporarily out of commission, so we had to run a development server in multithreaded mode.
One bug came across my inbox, flagging a feature that I had developed. Specifically a dropdown that displayed a list of saved user content wasn't updating. I attempted to replicate the issue on my machine, no-luck. Fired up my IE VM to test and, yet again, no luck. Weird.
I walked over to the tester's desk and asked her to walk me through the bug. Sure enough, upon saving an item, the contents of the dropdown did not update. Stumped, I returned to my machine and spoofed her account, wondering if there was an issue affecting her account within our mocked database backend (read: flat file). I was able to see the "missing" saved content. Now I was getting somewhere.
I walked back to her machine, opened the F12 Developer Tools, and watched the network traffic. The GET for that dynamically-populated list was resulting in a 304 status, and IE was using a cached version of the endpoint. Of course, I facepalmed as this was something I've not normally had to deal with as I usually use a cachebuster. However, for this new application, my team has been trying to do things as cleanly as possible. Wanting to keep our hack count down, I went back to my machine to see what our web framework could do.
Coming from a four-year stint in ASP.NET land, I was used to being able to set caching per endpoint via the
[OutputCache(NoStore = true, Duration = 0, VaryByParam = "None")] ActionAttribute. Sadly, there didn't appear to be something similar in Flask. Thankfully, it turned out to be fairly trivial to write one.
I found this post from Flask creator Armin Ronacher that set me on the right track, but the snippet provided didn't work for all the Internet Explorer versions we were targeting. However, I was able to whip together a decorator that did:
To invoke it, all you need to do is import the function and apply it to your endpoint.
from nocache import nocache @app.route('/my_endpoint') @nocache def my_endpoint(): return render_template(...)
I took this back to QA and was met with success. The downside of this manual implementation, however, is one needs to be religious in applying it. To this day we still stumble upon cases where a developer forgot to add the decorator to a JSON endpoint. Thankfully, code review processes are perfect for catching that sort of omission.