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.
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.
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.
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.
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"))
(setq eclim-auto-save t) ;; very important
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).
I used Awesome as my window manager for over two years and I really like it. It was my first “tiling” WM (although it’s described as a tiling wm, but more of a floating-tiling mix, see its features and non-features). Besides that, it was really configurable, and I mean it. Your configuration file (.config/rc.lua) may seem like half of the implementation of the WM, because there is defined which layouts are supported, how many tags to use, how to name them, the default keybindings, the mouse actions, etc. (here is mine). Probably, as with many WM, Awesome is too spartan for Gnome/KDE users. But again, it is for people that like minimalism. If you want to give it a try, do it, and do it for a week at least. It’s nice.
If it is soooo good, why did I change it? well, I had some stability issues with it for a while (which ended been problems with Xorg, so it’s not their fault). Also, there are two features I don’t like. First, while bringing lots of flexibility, the config file is usually “cluttered” with code you don’t want to see. As I said, it seems like half of the WM is written in the config file, so you have tons of code defining the default WM behaviour and, after a while, you stop feeling like you are configuring the WM and start feeling that you are patching it. Every new release was an exercise of retrofitting your changes to the new default config file, otherwise you may lose some of the new features bring by the update. Awful. Second, lua. The config file and other parts of the WM are written in lua, which is not part of my personal preferences. I may be biased by my lack of knowledge about programming in lua, or maybe not, even Julien Danjou, the original author of Awesome, has ranted about it.
So, one day I decided to try other tiling WM. I installed stumpwm, i3, ratpoison, and xmonad. I never got pass the first one.
StumpWM is not the most stable WM out there, nor the most lightweight (it requires a CL interpreter), and it has neither a large nor extremely active community (its latest stable release is from March 2010, but the repository is active so you get your code from there). Now, to the good stuff.
StumpWM is tiling, but has some support for floating “groups” (desktops). AFAIK, it doesn’t have the advance automatic tiling layouts of Awesome, so its window placement capabilities are more closely related to GNU Screen or Emacs Frames, but given that I usually have a single app in full-screen mode it doesn’t matter. What really make StumpWM shine is that it’s written in Common-Lisp. It’s at least as configurable as awesome while keeping your configuration file clean. Being Common-lisp, you can write a new function and it will override the previous one (not as powerful as advices in emacs, but close enough). If you don’t know lisp, learning it is very easy. Once you passed the feeling of “why there are so many parenthesis?” and get use to the prefix (+ 3 2) syntax, you will see it’s pure genius.
Edit:As pointed out by Seth in a comment, you don’t need to set your username nor password if you are going to use oauth and the master password, as I’m doing. My configuration snippet now reflects that.
I started to get interested on Twitter a few weeks ago, after some time having my account abandoned. I’m using Twittering mode, which is pretty nice: has support for oauth (twitter.el don’t have that, so don’t bother trying to use it), supports multiple url shorteners (I use bit.ly), easy navigation, tons of functionalities (check the EmacsWiki for a comprehensive list).
For those who doesn’t know it, Ibuffer is an replacement for BufferMenu, which is a buffer showing, à la Dired, all currently open buffers. Ibuffer allows you to easily filter, group and operate over the buffers, which is quite useful. It’s included by default on any version greater than 22.
You can directly invoke it using M-x ibuffer, or make it replace BufferMenu by setting the appropriated key binding:
(global-set-key (kbd "C-x C-b") 'ibuffer)
Here is the mandatory screenshot:
The interface shows information as columns (status, buffer name, size, major mode, filename), also allows you to do grouping (out of the box you have a single group, named “[ Default ]“). You can filter and sort the buffers (by major mode, filename, status, etc.) and operate over all or some of them (save, kill, search, etc.).
There are a lot of good posts around the web about Ibuffer:
emacs-fu has an introduction to Ibuffer, including other two alternatives considered (ido, elscreen), plus an example of buffer grouping.
Martin Owen’s blog also has an example of buffer grouping, plus a few more options (ibuffer-expert, ibuffer-show-empty-filter-groups, ibuffer-auto-mode, dired).
I haven’t been blogging for a long time, and while most of the “reasons” for that have to do with my amount of free time, I also needed a small push to do it. My blog engine, as stated in another blog post, is WordPress. It’s full featured and very nice, but as a guy who lives inside Emacs as much as possible, the web interface is sub-optimal.
For those who doesn’t know it Org-mode is an Emacs mode for /keeping notes, maintaining ToDo lists, doing project planning, and authoring with a fast and effective plain-text system/. If you want to learn more about it take a look at its manual or to the Talks and screencast.
Well, I’m definitely not the only one blogging using orgmode, take a look at this post in the emacs-fu blog (which by the way is very good) which is a nice introduction to orgmode capabilities and markup.
So, let’s assume you wrote your post in orgmode, and you have your wordpress blog, and you want to publish… you have the awesome tool org2blog. Very simple to use, you just do a checkout of the git repository
then copy the the corresponding files to a directory in your load-path. My .emacs looks like this:
(setq org2blog-server-url "http://www.rlazo.org/xmlrpc.php"
It’s pretty much self-explanatory.
My configuration is a single file where each post is a subtree, using the same idea that Sacha Chua explains in this post (BTW, that is also a nice blog to follow). If you read that post you will find that you need to patch the code from org2blog to add the command to create a blog post from the current subtree (which is org2blog-post-subtree ). But, since then, those changes have been integrated into org2blog repository, so no more patching required . Happy blogging!