ANN: Helm-dash, the documentation browser for emacs

This post is the official announcement of a minor mode Toni and myself have developed which allows you to browse documentation for many languages using helm machinery to drive the find-as-you-type. It's called helm-dash

Intro

Helm is gaining lots of traction lately in the emacs environment (there are over 50 helm-* packages is the melpa now). It's a find-as-yo-type helper which provides an easy way to act on the selections. 

Dash is a mac osX app which lets you browse what they call docsets. Docsets contain an sqlite db and some html with the documentation of a given topic.

helm-dash

The basic usage is pretty simple:

• helm-dash-install-package will give you the available docsets in the official repo (we'll choose Redis for testing).
• Add the docset to either the global variable helm-dash-common-docsets. 
  

   (setq helm-dash-common-docsets '("Redis")) 

• execute the interactive command helm-dash
• Type some letters that match a redis command you want to look for (push, for example)
• Press RET when you are on the command you want. Your favourite browser should open pointing to the documentation.

buffer-local docsets

For further configuration, we allow per-buffer sets of docsets. Let's say you want the GoLang docset available, but just in go-mode buffers. Install Go docset, and evaluate the following elisp:

(defun go-doc ()
  (interactive)
  (setq-local helm-dash-docsets '("Go")))

(add-hook 'go-mode-hook 'go-doc)

Then, when you open a go buffer, helm-dash will search both Redis and Go.

Here's a demo of the basic usage. (Mind that the video is not setting the variables accordingly because they were already set)

 

Try it, patch it, or talk about it, we'd love to hear your comments and improve it. 

The package has been developed and tested under linux.It should work on Mac OSX but it hasn't been tested there.If you find any issue on Mac, please, Pull Request :)

Evil: The exact amount of vim in emacs (but no more than that)

I love emacs, but I also love modal editing.  Evil was (and vimpulse before that), was a great finding.

What I want is to have a normal mode where most commands feel like vim, and an insert mode where most commands feel like emacs, so c-p would do previous-line in insert mode instead of autocomplete word. Here are some of my tricks (many of them gathered from other people's configs)

99% emacs insert mode

Although using lots of insert mode commands when I was using vim daily, now I hardly find the necessity for them.

(setcdr evil-insert-state-map nil)
(define-key evil-insert-state-map [escape] 'evil-normal-state)

And that's it. with this, you're mostly done. In insert mode, every key but escape will behave as in plain emacs.

Undo-tree? nah (99% of vim in normal mode)

I still prefer emacs' undo-redo schema than the undo-tree. In the docs (also in the code), evil states that undo-tree will be used if available, and regular undo-redo will be used in case it's not there. That sounds fine, but if you get evil from elpa, undo-tree will be downloaded and installed without asking.Uninstalling undo-tree afterwards is not an enough because when loading, evil will complain it has some unmet dependency.

To make evil forget about it I edited the evil-pkg.el in my ~/.emacs.d/elpa/evil-xxxxxxx/ dir deleting undo-tree as a requirementand leaving it like this:

(define-package "evil" "20140109.605" "Extensible Vi layer for Emacs." '((goto-chg "1.6")))

c-r tries to redo

Just remap the desired key in the chosen mode to your prefered function.

(define-key evil-normal-state-map (kbd "C-r") 'isearch-backward) 

With these few tricks you can hack further to fine tune your keybindings and submodes inside evil. If you dig deeper into its code, you'll see it's quite well organized and quite clear.

Emacs keybindings everywhere

If you're using conkeror or keysnail you know how nice it is to have the usual keybindings in your browser.

Just in case you aren't using them, or if you're using them but want to have c-a, c-e,etc... in many linux desktop apps, here's a little trick.

Open (or create) the file "~/.gtkrc-2.0" and put the following line

gtk-key-theme-name = "Emacs"

Save, and open plain firefox. Then in any text field, try c-a, c-e, c-k . Neat, right?

You're welcome :)

Hide mouse cursor while typing

Long time ago I already blogged about an emacs way to move the mouse cursor when you are typing close to it.


Yesterday I discovered that there's a much more simple way to unclutter your screen making the cursor invisible.

(setq make-pointer-invisible t)

Voilà, that's it.

lua and luajit

In the lua workshop, lots of nice topics were raised, but something that striked me was when everyone agreed that writting lua for luajit or for the official lua VM was totally different, and ppl had different mindsets when writting for one or the other.  I know there's a big difference on how to write bindings to C (luajit being more fond of ffi and stock lua prefering the Lua C Api.

If you wanna know a bit more on how luajit works and where it gets its blazing speed, here you have some links to explore it, and to get a grasp of differences between lua implementations.

Agentzh talking about why he (and cloudflare) are targeting mostly luajit:

Nice introduction to luajit. In fact it's mostly lua, but maybe the second part will be more targeted to luajit

Mike Pall has written a few times about how luajit tracer works.

And here it's a functional library which, not being directly linked to luajit, it makes a really nice usage of iterators to build code structures lazily and make the traces jittable by luajit. nice code read.

If you're on the stock lua vm, here you have a paper with a good overview of how lua 5.0 was implemented.

Also, there are a lot of libraries and apps that are targeting just the luajit implementation. It creates some nasty splits on the community, but you know... these things happen.

Reading lua source

As I'm digging deeper into lua, I'm from time to time looking at the lua C source code itself, to see how something is implemented.

It's nice to see a highly commented code with some quite clear parts which goes right to the point. Quite tough though and dense at many other parts.  The whole lua 5.2.2 has a bit more than 14K lines. Not bad for the language, compiler, vm, repl, C Api, and libs.

Anyway, here's a couple of links I found useful in case you want to have a deep look at the lua source:

• Mike Pall suggestions on a sane reading order of the lua 5.1 source
• Guide from the Lua Wiki

Lua Workshop 2013

I was lucky enough to be in the Lua Workshop 2013. Held in Toulouse.

I had lots of fun there, both in the conference and outside it. For me, one of the most important topics raised were the speciation of the Lua world.  Stock Lua, LuaJIT, openresty, luvit ... Many different environments for which lots of packages do not work in different environments (lua-redis and lua-resty-redis, for example). 

This 'problem' extends to other parts of the language and comunity, like packaging. You cannot use luarocks for Luvit, or, the openresty packages are not in LuaRocks. The community is aware of that, and trying to find some compromises to create a healthy ecosystem.  I loved when LuaDist, LuaRocks and the debian packager of lua started an 'impro' discussion on issues they had, pros and cons.

Other talks were also amazing, like Roberto's one: 'Lua, past present and future'. Great way to expose the Lua history and philosophy and reasoning behind some of the features that Lua came to have nowadays. (Spoiler for the future: They are working on Macros!!!)

People modifying the vm to adapt it to their needs were also really wicked cool things we saw there.

Thanks to 3scale for sponsoring my trip, and to the Lua community for being so awesome :).