Amit's Thoughts

From Amit Patel

Long ago, I used XEmacs, and its buffer-local faces to highlight the active window and modeline. When I switched to Emacs, I was sad to see that it didn't have buffer-local and window-local faces. It does have a separate face for active and inactive modelines though.

Today I learned that Emacs 23 has a buffer-local face remapping feature. I'm using this to highlight the active buffer (not window):

;;; highlight-focus.el --- highlight the active buffer

;; Author: Amit J Patel <amitp@cs.stanford.edu>

;;; Commentary:
;; 
;; I find that I'm not good at tracking when focus changes across
;; apps, windows, and within a window. As much as possible, I try to
;; have all my applications somehow draw attention to what has
;; focus. In X11 I marked the focus in red. In Firefox I marked the
;; text fields in yellow. This Emacs package highlights the active
;; buffer. It's inspired by an earlier package I had written for
;; XEmacs, which changes the window color and modeline color for the
;; current window.
;;
;;; History:
;; 
;; 2013-05-10: Rewritten to use the Emacs 23 "remap faces" feature.
;; 2007-04-16: Initial version, temporarily highlighting the active buffer

;;; Code:

(require 'face-remap)
(defvar highlight-focus:last-buffer nil)
(defvar highlight-focus:cookie nil)
(defvar highlight-focus:background "white")

(defun highlight-focus:check ()
  "Check if focus has changed, and if so, update remapping."
  (unless (eq highlight-focus:last-buffer (current-buffer))
    (when (and highlight-focus:last-buffer highlight-focus:cookie)
      (with-current-buffer highlight-focus:last-buffer
        (face-remap-remove-relative highlight-focus:cookie)))
    (setq highlight-focus:last-buffer (current-buffer)
          highlight-focus:cookie
          (face-remap-add-relative 'default :background highlight-focus:background))))
    
(defadvice other-window (after highlight-focus activate)
  (highlight-focus:check))
(defadvice select-window (after highlight-focus activate)
  (highlight-focus:check))
(defadvice select-frame (after highlight-focus activate)
  (highlight-focus:check))
(add-hook 'window-configuration-change-hook 'highlight-focus:check)

(provide 'highlight-focus)

;;; highlight-focus.el ends here

There's some more tweaking I need to do but so far it seems to be working reasonably well.

Labels: emacs

There are at least three Mayan calendars. I was listening to the How Stuff Works: Mayan Calendar podcast, and learned that the Mayan calendars are not as strange as I expected them to be. Let’s first look at how our years are structured:

When the last component overflows (from 9 to 0), we carry one and increment the decade. When the decade overflows we increment the century. This is how base 10 numbers work.

Now let’s look at how dates are structured:

When the last component (day) overflows from 31 to 1, we carry one and increment the month. When the month overflows from Dec to Jan, we increment the year. This is very similar to how base 10 numbers work, except that each component has its own rules for when it overflows, and months don’t all have the same number of days.

How are weekdays numbered? We can say both the day of week and the day of month, and increment both each day:

The Mayan Tzolk’in calendar works like this. Both components are incremented each time. One component has 20 days and the other has 13 days, and they line up every 260 days.

The Mayan Haab calendar is more conventional, lasting 365 days. There are 18 months each with 20 days, giving 360 days, plus an extra 5 days to make it fill a year. They didn’t handle leap years.

The Mayan Long Count calendar is the one people are worked up over. There are five (or maybe nine) “digits”, each base 20 except one that’s base 18 to match the months of the Haab calendar. However the Long Count calendar doesn’t include the extra 5 days, so it doesn’t stay lined up with Haab.

What’s the big deal about 21 Dec 2012? It’s 13.0.0.0.0, at least under the most common translation of our calendar to the Mayan calendar. It’s sort of like how people celebrated the year 2 0 0 0. It’s nice to celebrate a bunch of zeros. Some interpretations say that it doesn’t go to 13.0.0.0.0 but resets back to 0.0.0.0.0, but it’s not universally agreed upon, and some say that there are four more places in the calendar system, so it’d be 0.0.0.0.13.0.0.0.0, resetting only after 63 million years.

In any case, the thing I find strangest about the Mayan calendar systems is that there are so many of them, somewhat incompatible with each other. In addition to the three I described above, there’s a 9 day cycle, a lunar cycle, a Venus cycle, and a few others. See the Wikipedia page for a reasonable overview. If you use Emacs, the Mayan calendar is included, and you can use M-: (calendar-mayan-date-string) to get back a string like "Long count = 12.19.19.17.15; tzolkin = 12 Men; haab = 18 Mac".

Appendix: 13.0.0.0.0 dates

There are different translations between Mayan dates and our dates. A lot of this has to be reconstructed because Christians burned the Mayan books. I translated the Wikipedia list of date translations into a list of dates for 13.0.0.0.0:

When using Emacs I’m often switching buffers or opening files, so I’m always on the lookout for ways to make those operations more pleasant.

A while ago I tried Anything.el. Anything is like Quicksilver for Emacs. It’s powerful but I found it confusing to set up. Emacs-Fu had a blog post about configuring anything.el, and I used that for my setup.

For the most part, I use it instead of find-file:

When I saw that Helm was the successor to Anything, I decided to switch to Helm and simplify my setup. I was pleasantly surprised by how easy Helm was to set up compared to Anything. Here’s my setup, binding Alt+T (inspired by Textmate) to invoke helm-for-files:

(require 'helm-files)
(setq helm-idle-delay 0.1)
(setq helm-input-idle-delay 0.1)
(setq helm-c-locate-command "locate-with-mdfind %.0s %s")
(loop for ext in '("\\.swf$" "\\.elc$" "\\.pyc$")
      do (add-to-list 'helm-c-boring-file-regexp-list ext))
(define-key global-map [(alt t)] 'helm-for-files))

This uses the default helm-for-files setup, which lists, in order:

1. ffap (find file at point)
2. buffers (names of all open buffers)
3. recentf (recently opened files)
4. bookmarks (which I don’t use)
5. files-in-current-dir (like find-file)
6. locate (files in other directories)

However, I don’t want locate for all files on my disk; I want my home directory, minus a few subdirectories that contain files I never open. For this, I use a shell script to filter the results. On a Mac, use mdfind -name instead of locate; it’s updated in real time instead of nightly.

#!/bin/bash
mdfind -onlyin $HOME -name "$@" \
    | grep -v "$HOME/Library/" \
    | grep -v "$HOME/Pictures/" \
    | grep -v "$HOME/Music/"
mdfind -onlyin $HOME/.emacs.d -name "$@"

(Note: if you want to use mdfind to search contents and not only filenames, take a look at helm-c-source-mac-spotlight.)

More thoughts:

• Ideally, I don’t want to have to think about whether I’ve already opened a file or not. In practice I do treat switching buffers and opening files differently. I use Alt+J and Alt+K for switching buffers in the same directory (see this blog post). I sometimes use ido-find-file (bound to Alt+O) for opening a file in the same directory, but I’m increasingly using helm-for-files even in the same directory.
• Since mdfind is so fast with an SSD, I reduced the initial delay from 300ms to 100ms. That made it feel much better. You may need to experiment with the delay setting.
• The same file can be in the buffers list, the recent files list, the current directory list, and the locate list. I’d like to see each file only once. I’m sure helm can filter these out but I don’t know how.
• It'd be nice to not have it print out the full path every time, but I haven't figured out how to do that.

There are so many amazing things Helm can do; I’m only using it for this one feature, and it’s been great.

Labels: emacs

I find that I often don’t know a structure or abstraction until I’ve worked with something more concrete. This happens in programming but it also happens when creating structured information.

While helping Wild Shadow Studios with Realm of the Mad God, we held our discussions in Google Wave for two years, until Google shut it down. Why did we use a tool everyone else thought was useless?

• Group Chat: The 3–6 of us could chat about the game.
• Asynchronous: We could continue conversations while not all of us were online.
• Nesting: We could reply to individual points made in another message.
• Attachments: We shared test binaries or screenshots.

It was nice for keeping everyone “on the same page”.

Wave didn’t work well for us when it came to adding structure. We had thousands of chat messages in the system, but when a bug or feature or idea came up, there wasn’t an easy way to transition into a task tracker. As a result, those kinds of things were too easily forgotten.

When I use tools like Asana or Trello or Cohuman, they want me to start with structured data, but they don’t handle the informal unstructured nature of IM or Wave. Where do those tasks come from? They came from somewhere, but that history isn’t preserved when you create a new task in a task tracking tool.

I want a tool that lets me hold unstructured conversations, then extract portions of conversations that led to a task, and move them into my task tracking tool. Unstructured comes first for me; structure is what I add later, once I understand what structure I want. Databases and most structured tools I use get this wrong — they ask me to decide the structure first. Spreadsheets, Wikis, Wave, and most unstructured tools also get this wrong — they let me easily work without structure, but don’t offer me a transition to something structured. JotSpot, before it was bought by Google, is the only tool I tried that had a smooth transition from unstructured to structured.

It’s also possible I’m cursed to like things that have a lot of potential, but can’t be understood in five minutes, and thus are doomed to niche status. I think Wave and JotSpot both fit into this category.

Labels: structure

Dirk-Jan C. Binnema’s mode-line blog post inspired me to post about my own Emacs mode line configuration. I found the default mode line to be too busy for my tastes. I removed most of it and added to the features I care about most. Here’s what it currently looks like:

Labels: emacs