Full Of Caffeine

As you might already know, I use emacs+orgmode for most of my information management needs and GTDness. There’s really nothing else out there that reaches the simplicity of plain text files managed by such a powerful PIM meta-framework.

I’ve been also using Peepopen, the new fuzzy-search based file-picker from topfunky. Peepopen indexes a list of files in a given directory and allows you to reach the wanted file with as few types as possible, taking advantage of fuzzy-search logic.

You could think it would be used only to pick up files from a software project, but the truth is, it can be used to pick files wherever you want.

I keep a reference system by piling up files into my ~/org/wiki directory. If I have something worthy to write about any subject, or if I need to study about something, I, just create a new org file in this directory and start typing.

In this sense, I’m going off the patterns of orgmode, which encourages few big files managed by the powerful agenda view. If I were being a org-purist, I would probably be using a big reference file, and each org top-level headline would separate the different contents. However, I can’t really get used to that and I prefer to separate my subjects physically into different filenames, at least for reference-like data. I might be adding one or two very important files from the wiki dir into the agenda if it is something that I really need to get my attention into currently, but that’s it. Besides, org-agenda doesn’t work well if you add tons of files into its lists, it just gets too slow.

So, what I wanted was a quick and easy way to get to my “wiki” pages — “Well why not use Peepopen” — I asked myself. Well, why not?

What I did was to dig into peepopen.el, I then took a glance at the peepopen-goto-file-gui function. Happened this was the function I needed. Following the path of least effort, I just copied the function definition and pasted on my org.el configuration file. Then I modified it to accept an argument, which is the root path for Peepopen:

(defun peepopen-goto-file-gui-manual (arg)
“Uses external GUI app to quickly jump to a file in the project.”
(interactive)
(defun string-join (separator strings)
“Join all STRINGS using SEPARATOR.”
(mapconcat ‘identity strings separator))
(let ((root arg))
(when (null root)
(error
(concat
“Can’t find a suitable project root (”
(string-join ” ” *textmate-project-roots* )
“)”)))
(shell-command-to-string
(format “open -a PeepOpen ‘%s’”
(expand-file-name root)))))

(defun find-wiki () “Find files in the wiki dir” (interactive) (peepopen-goto-file-gui-manual “~/org/wiki”))

(global-set-key (kbd “s-w”) ‘find-wiki)

I then defined a function find-wiki, which happens to be a simple wrapper that calls peepopen-goto-file-gui-manual with the path I want. Finally, I bind super-w to find-wiki.

Then, whenever I type s-w, Peepopen fires up listing my reference files, and allows me quickly pick and open the one I want in emacs. Beatiful and simple!

The point is, you can use Peepopen to pick anything, anywhere. It will use the current opened file as reference by default, but if you want to force a location, you can use this function and pass the path as argument.

It would be cool if Peepopen would allow me to type in a filename that doesn’t exist and visit this path on emacs

You can check the code for this and more on http://github.com/celoserpa/emacs-starter-kit, forked from topfunky’s starter-kit.

If you are compiling emacs from source on OSX (which you should be doing) or even if you are using a pre-packaged version from emacsformacosx, you might be asking yourself why you can’t run emacs from the CLI.

I didn’t have time to dig into the whys of it, but it has to do with the Emacs binari not finding some resources because of the use of relative paths.

Anyway, I’ve came up with a very simple solution. Just create a executable file with the following contents:


/Applications/Emacs.app/Contents/MacOS/Emacs $@


The $@ will delegate command line arguments passed to this script to the Emacs binary.

Make it executable (chmod +x emacs) and put it on any directory that is part of your PATH, and now you should be good to go.

This is quite useful to, for example, run emacs with –debug-init or any other CLI use for that matter.

Now, everytime I think of nginx, I’ll think of agile. Period.

This tiny web server is not only tiny in its implementation, it’s also tiny in the sense of being simple.

Just now I had to setup a Rails app running in a subdomain locally, because first, I was mapping my IP to a dyndns domain in order to test a google gadget, and second, the gadgets.io.makeRequest doesn’t support a URL param with a port number (probably a bug in the iGoogle OpenSocial implemention, but anyway, not the point here), what I did was to add the following to the already configured virtualhost on my nginx.conf:


server {
listen 80
server_name localhost

proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-FORWARDED_PROTO https;
if (-f /index.html){
rewrite (.*) /index.html last;
}
proxy_pass http://localhost:3000/$1;
}


Restarted nginx and… had the rails site there. I have an issue though, since all resources are mapped to a relative URL to the host and the host doesn’t include /railssite, all of them fail to load (css, js, images), which is not a problem in this specific case, since I only need to access an action that returns some XML to the gadget (But if you know a way to run an app in a path and still load resources without modifying the app itself, please, share!).

Now, I’m sure it would be easy to do that with Apache, I know because I’ve done before. However, what amazed me was the “principle of least surprise” — I didn’t really look into the documentation, just used some common-sense based on previous skills and it worked.

I just like nginx a tad more