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.

So, I have migrated to Clearly by Evernote. It provides basically the same distraction-free browsing experience.

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.

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.

Slides

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):

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

Original from http://xach.livejournal.com/296022.html

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.

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).