Disable Org-mode Babel evaluation confirmation per file

Today I started experimenting with Babel, part of org-mode that enables execution of code defined inside your org file. It’s great, although it’s taking me a little effort to get use to it.

Well, as with any mechanism that executes arbitrary code in your machine, it’s a security risk, so by default, org-mode ask you prompts you for confirmation before executing any block of code. Well, what if you are writing the org file and the code can be considered trustworthy, but you are asked every. single. time. whether it’s OK or not to execute that file? As I found in Irreal’s blog post, doing that is as easy as putting

# -*- org-confirm-babel-evaluate: nil -*-

at the beginning of your org-file. In retrospective, it’s the obvious solution. I always forget file vars.

About interactivity and immediate feedback

TL;DR Watch THIS.

Jeff Atwood at Coding Horror has made a couple of really interesting blog posts about the true interactivity and feedback loop delay. Basically, the longer it takes to get feedback about what you are doing, the worse.

In What you can’t see you can’t get, about document authoring, Jeff mentions the gripes of working with WYSIWYG editors because of hidden format tags or invisible whitespaces. The current solution to this is using LaTeX or markup languages, where you can focus on content and intermix formatting tags whenever is necessary. I deeply believe this is a way better approach. BUT there is a long feedback loop between what you are writing and the actual document being produced. Usually, you write some content, save the document, compile (a couple of times if necessary), and then, if everything goes according to plan, you can see your document in a pdf/dvi viewer. When I was an undergrad student I remember my friends and I learning LaTeX. Everybody knew that, if you took to long to compile your document, you had to pray to the LaTeX gods for it to compile correctly, otherwise you were trap in a bug hunting quest for the next half an hour. Eventually, for any non-trivial document, you compile frequently and split your screen in two, in one side you have your text editor, and in the other your document viewer, to be able to preview your work.

Two window setting for later

Source http://www.codinghorror.com/blog/2012/03/what-you-cant-see-you-cant-get.html

What about being able to switch between the two easily, while keeping track of where each part of the document came from? Enter Gliimpse project.

Cool!

But, in Visualizing code to fail faster, we enter the world of Bret Victor and his principle: Help ideas flourish by giving their authors tools with immediate feedback. He argues that, by allowing people to see what they are doing in the computer right away, instead of having to imagine it until the computer is ready to display the results, you strength ideas and enable more creativity and better understanding. At first it didn’t felt attracted to the concept, but after watching his talk at CUSEC I’m convinced.

Make some time to watch the video. It’s AWESOME, really. I mean it.

Google Chrome extensions

I use Google Chrome every day, and while it’s pretty good by itself, I’ve found a few extensions that make the whole much better. Here there are:

Google QuickScroll

I hate when I search for something in Google and then, when I follow the link, I have to search again inside the page to find the snippet of content I wanted. Google QuickScroll solves this.

Google QuickScroll

IReader

Clutter… or awful theme… or tiny font, or all the above. Some pages are almost unbearable to read. IReader makes reading news, blog posts and alike wayyyyy better. It creates a “light box”-like pop-up where all you see it’s the real content. Big plus, if an article is split in several pages, IReader joins all the content together so you don’t have to follow 10 links to read the whole thing.

IReader

Keyboard Navigation

With this extension you can follow links without using the mouse. Keyboard Navigation “tags” every link in a webpage with a letter, or letters, then, you type that combination to select the link, and press enter to follow the link. Quick and easy

Keyboard Navigation

Lookup Companion for Wikipedia

Finally, Lookup Companion for Wikipedia embeds a minibrowser in your toolbar from which you can search the wikipedia and satisfy your curiosity without leaving the current page you are browsing.

Wikipedia Companion

Showing git branch in zsh

Lately, I’ve been working a lot with several git and mercurial repositories. Keeping track of the current state of the repo (branch + staging changes) gets boring quickly, so I decided to use zsh facilities to include that information in the prompt. The preferred way of doing it is with vcs_info, available since zsh beta, version 4.3.6-dev-0+20080929-1 (ref); older guides will use custom functions, which is unnecessary, unless you want to go beyond the basic support provided by this module.

My configuration includes information about staged(stagedstr) and unstaged(unstaged), displayed as “:S” and “:U” respectively:

autoload -Uz vcs_info
setopt promptsubst

zstyle ':vcs_info:*' check-for-changes true
zstyle ':vcs_info:*' stagedstr ':S'
zstyle ':vcs_info:*' unstagedstr ':U'
zstyle ':vcs_info:*' enable git hg
zstyle ':vcs_info:*' actionformats \
  '%F{5}(%f%s%F{5})%F{3}-%F{5}[%F{2}%b%F{3}%c%u|%F{1}%a%F{5}]%f '
zstyle ':vcs_info:*' formats       \
  '%F{5}(%f%s%F{5})%F{3}-%F{5}[%F{2}%b%F{5}%c%u]%f '

precmd() {
    vcs_info
}

RPROMPT='${vcs_info_msg_0_}[%T on %D]'

And here is how it looks (original):

http://media.rlazo.org/pics/zsh-git-screenshot.png

A few things I struggled with, basically because I didn’t read the docs:

  • You must set setopt promptsubst otherwise, ${vcs_info_msg_0_} is not going to be recognized.
  • If you use %c or %u for change tracking, you should set to true check-for-changes (see code).
  • Don’t forget about precmd()

Here are other examples: 1, 2

Enjoy

Posted in Zsh

Change ediff options

Ediff is a great tool for diffing to files/buffers and merging changes. One thing I liked is that you can make it ignore white-space only differences. I used to do activate it every time. Finally I got to the point that I wanted to make the change permanent, so I followed EmacsWiki advice:

Whitespace sensitivity – Include ‘-w’ in ‘ediff-diff-options’.

So, I did a quick (setq...) but it didn’t work. After some googling, I came across this message. Seems like you have to make the changes using customize, otherwise it won’t work. So, if somebody else is having this problem, making the changes using customize (M-x customize-group RET ediff-diff) is the way to go.

Emacs eclim

I’ve been doing some java development lately and while Eclipse is nice and IntelliJ IDEA is a very good alternative, both are nowhere near emacs in text manipulation capabilities. On the other hand, emacs is awesome in every way except context sensitive completion and re-factoring across a project, a must for Java.

From the eclipse perspective, there are plugins that simulate emacs keybindings, but I was never truly comfortable using them. Emacs is more than its keybindings. From the emacs perspective, there is the Java Development Environment for Emacs, or JDEE, but it doesn’t seem to be under active development; while it gained some momentum last year, their devel mailing list statistics show that only 11 messages have been send this year.

Then, I found Eclim, and as stated in their homepage: “The primary goal of eclim is to bring Eclipse functionality to the Vim editor. The initial goal was to provide Eclipse’s java functionality in vim, but support for various other languages… have been added and several more are planned.”

Basically, eclim has two parts, a java plugin that hooks into eclipse and exposes some of its functionality, and a VIM plugin. I like this approach. For a lot of people, emacs and vim are almost their natural environment, so making other tools provide extra functionality to them instead of trying to simulate the editor experience is the way to go.

For emacs, you have the Emacs Eclim project, hosted in github, which is the equivalent of the vim plugin. To use it, first install eclim, then download emacs-eclim from github, and finally add to you .emacs:

(add-to-list 'load-path (expand-file-name "/path/to/emacs-eclim/"))
(add-to-list 'load-path (expand-file-name "/path/to/emacs-eclim/vendor"))
(require 'eclim)

(setq eclim-auto-save t) ;; very important
(global-eclim-mode)

And now you are ready to go. The main feature missing in emacs eclim is doc searching, but AFAIK it’s provided by eclim, so it shouldn’t be too hard to implement the emacs part. Emacs eclim is under active development.

As a side note, if you want to do some Android development, I deeply recommend you to use IntelliJ. It has built-in Android support and works great. A month ago I tried to setup Eclipse’s android plugin and it was extremely frustrating. So, try IntelliJ if you want to experiment a different IDE and can withstand its no so pretty interface. (They have a community edition which is OpenSource, check it here).