Zane's Blog

Following up on my last post, here is how you can define a custom operator for evil-mode (which is where the true power of Vim comes into play).

It is trivially easy to set this up using evil-define-operator. Here is the code:

(evil-define-operator evil-narrow-indirect (beg end type)
  "Indirectly narrow the region from BEG to END."
  (interactive "<R>")
  (evil-normal-state)
  (narrow-to-region-indirect beg end))

Now all that is left is to bind it to a key! I'm using "m":

(define-key evil-normal-state-map "m" 'evil-narrow-indirect)
(define-key evil-visual-state-map "m" 'evil-narrow-indirect)

Eval all of this, and now we have everything in place to say "mit" or "mi}", etc.

I'm once again an Emacs convert. I used Emacs a fair bit back in 2011 as my main editor (when vimpulse was a viable alternative to native Vim and I forced Emacs upon myself for as long as I could), I even wrote a few posts about extending it. But eventually I gave it up as it was starting to feel sluggish with everything I was throwing at it (looking back, it was more than likely just a bad minor-mode or two).

However in the time I've been away from Emacs I feel as though the eco-system has really modernized. We now have emacs-starter-kit and prelude to get you up and running quickly with sane defaults, we have package.el since Emacs 24, along with MELPA as a maintained repository of elisp packages, and even a set of decent color themes! And of course I can't leave out evil (the extensible vi layer) which I could not do without.

CoffeeScript v1.5.0 was released a few days ago. One of the new features touted in this release was the addition of "Literate CoffeeScript". This was an additional mode in the compiler that allows it to process files ending with .litcoffee that contain both Markdown and CoffeeScript together to form a literate program.

Literate programming, introduced by Donald Knuth, is a technique of writing programs in the natural order and style that you would use if you were to verbally describe the way a program works. Literate programming is designed to break the order of source code required by traditional compilers. It can be fun to build programs in this way by simply starting a document with a description and a list of headers for each feature.

I thought it was really cool to see this in CoffeeScript, but it made me wonder why exactly this needed to be a CoffeeScript extension and not another tool available for any language. So I wrote a small utility to do exactly that.

There are several utilities out there already for assisting with literate programming, however I have a crazy case of Not Invented Here so I decided it would be fun to write my own take on the idea.

By now, most people that keep up to date with tech news will have heard about the small $70USD 3D motion sensing controller by Leap Motion (make sure to see the demo if you haven't already) that is claiming to open up some incredible possibilities for the future of computer input.

In a nutshell, the Leap is a device similar to Microsoft's Kinect; it uses a pair of infrared cameras and some clever math to build a point cloud and detect hands + fingers + tools inside of this point cloud and return information about these using a simple API. Though where the Leap really excels is in speed and accuracy. This thing is fast, in my brief test on an i7 CPU and USB3 connection I was seeing between 2-5ms of latency, which is perfect for an input device and quite a feat considering the accuracy, which is right down to the millimeter level.

After a short stint of hacking on WacomWebPlugin I've tagged the repository as v0.1 and released my first ever PKGBUILD for ArchLinux. If you have a Wacom device on Linux then go and try it out!

Since the last update:

• Device id is no longer hardcoded.
• The eraser device is now also used.
• No more phantom presses since we use the proximity events to change the pen type.

All in all the plugin is feeling a lot more stable than before.

Nine months ago, I published WacomWebPlugin , a project aiming to implement the Wacom Tablet Plugin API on the Linux OS where the official browser plugin isn't available. The plugin allows websites to make use of tablet features such as pressure-sensitivity. The most well known user of this API is DeviantART's Muro web app.

My initial proof-of-concept was hacked together using the FireBreath framework, which makes it easy to implement cross-platform and cross-browser plugins. I was able to get enough of a plugin working to allow basic pressure-sensitive drawing on Muro. However, the code was crap and was full of repetition and global state. I published it nonetheless.

Over the last couple of days I've had some interest from a curious Githubber wanting to port his notetaking program (hoodle ) to the web, so I've decided to revive and rewrite the project. After updating my copy of FireBreath and being unable to compile the plugin without some modifications, I realised that I don't really need the large FireBreath dependency after all (the plugin will likely only ever target Linux).

For the first time in.. a while, I have had a sudden inclination to do some updates to HashTWM . So far I've mostly just done some cleanups and code style changes, but one major feature that I've just added is the ability to whitelist a few window classes and have HashTWM only tile those windows, as opposed to all (or blacklisting). I believe this was a feature suggested to me a while ago that I had misinterpreted (durr). Oh well it is finally done and is very useful :)

Just in time for the end of the world.

What's Next.

I have conceived many pet projects with the goal of replacing HashTWM in the long run, but I think that the best chance that HashTWM has is for me to port features from those prototypes back into the mainline.

The major features I will be wanting to add are:

• A scripting language of some kind, at least as a way of enabling more powerful configuration. Leaning towards a Scheme (maybe Chicken).
• More powerful keybindings (and even chaining) using a keyhook (from HackWM ).
• Some kind of remote, for external displays/control. This should keep it nice and light while allowing you to see tags, and other useful info.

Hopefully as my Windows laptop gets more use in the coming months I will be able to contribute more time to HashTWM. Thanks to everyone that has been following the project and still has an interest :)

Happy Holidays!

I don't use a whole lot of Ruby in my day to day work, but it is a language that is very quickly growing on me for several reasons.

As I further integrate jekyll into my website pipeline, I'm finding more of a need to extend it with plugins, no surprises there. One particular plugin that I was previously using is jekyll-assets . I have since moved over to jekyll-asset-pipeline as it better serves my needs, but this article remains.

Jekyll-assets provides a sprockets based asset pipeline, closely mirroring the pipeline present in Rails. The asset pipeline allows me to quickly concatenate and process multiple JavaScript and CSS files into single output bundles; reducing the amount of requests made when loading a page, and thereby improving load time. I also use it to build CoffeeScript and SASS stylesheets.

What is Monkey Patching?

Monkey patching refers to the ability to modify existing code at runtime and outside of regular means (ie. editing the original source). This can be useful as a way to add often-needed functions to a basic type, and in the case of Ruby where everything is an object, this can even include adding methods to numbers themselves (which are of the FixNum class), for example:

I'm back again to share a quick hook for updating a jekyll based website or blog upon pushing to gitolite .

What is Jekyll?

jekyll is a small website/blog generator written in Ruby. It takes several templates, pages and posts, and combines them into a fully functional site ready to be served by any webserver.

I've used Jekyll to power this blog for a few months now as the ability for me to write posts in Markdown and keep them stored in git is highly valuable for me. Previously I have been building the site locally and pushing the generated content to my VPS, but this is suboptimal and causes massive changesets (as you can imagine). Time to move that processing to the server where it rightly belongs.

Continuing this series of posts on Gitolite hooks, this time I will be adding live project documentation to Redmine, using Doxygen.

Background.

Documentation is often as important as code itself, especially when working in a team or introducing new programmers.

But keeping generated documentation up to date is a pain, and it really shouldn't be.

At CodeShack we use Redmine as our project/task tracker. From here our developers have access to relevant projects with the ability to directly view the repository for that project, so why not add a "Documentation Tab" too?