About two days ago, one of my coworkers who started using emacs around the same time as I did and who comes from a similar vim setup as mine, introduced me to perspective.el.

From the docs:

perspective.el provides multiple workspaces (or "perspectives") for each Emacs frame. This makes it easy to work on many separate projects without getting lost in all the buffers.

Since I inmediatly found it so convenient I wanted to make it faster to switch between perspectives by setting up a keybinding for it. Sadly, the provided way to do it was to use the persp-next function which has the drawback of prompting for a name when you've reached the last perspective. So I went and checked how persp-next works and found this, which is pretty straightforward:

(defun persp-next ()
  "Switch to next perspective (to the right)."
  (interactive)
  (persp-switch (nth (1+ (persp-curr-position))
                     (persp-all-names))))

It showed me that a) (persp-all-names) returns the list of all the available perspectives and b) I can call persp-switch with the name of the perspective I want to go to as an argument. With that in mind, I wrote this little function that makes perspective cycling behave the way I want.

(defun persp-cycle ()
  "Cycle throught the available perspectives."
  (interactive)
  (let ((next-pos (1+ (persp-curr-position)))
        (list-size (length (persp-all-names))))
  (cond ((eq 1 list-size) (persp-switch nil))
         ((>= next-pos list-size) (persp-switch (nth 0 (persp-all-names))))
         (t (persp-next)))))

When there are no other perspectives besides the current one, it'll prompt you for a name. Else, it'll just jump to the next perspective and go back to the first one after reaching the end of the list.

There's a number of reason why you'd want to program your Arduino device as a regular AVR MCU. For me it was having to do some tests I'd later have to run on a normal AVR board and only having an Arduino board available. Turns out the built-in STK500 ISP on the Mega 2560 is supported by avrdude.

The whole compiling/flashing shebang can be done with the following Makefile (slightly modified from the one found here).

You'll probably have to modify the DEVICE variable if you're using something other than OSX and the SOURCES one if you're using C++ instead of C.

NAME := main
HEX := $(NAME).hex
OUT := $(NAME).out
MAP := $(NAME).map
SOURCES := $(wildcard *.c)
HEADERS := $(wildcard *.h)
OBJECTS := $(patsubst %.c,%.o,$(SOURCES))

MCU := atmega2560
MCU_AVRDUDE := m2560
PARTNO := stk500v2
DEVICE := /dev/tty.usbmodem*
BAUDRATE := 115200
AVRDUDE_FLAGS := -F -V -D -v

CC := avr-gcc
OBJCOPY := avr-objcopy
SIZE := avr-size -A

CFLAGS := -Wall -pedantic -mmcu=$(MCU) -std=c99 -g -Os -DF_CPU=16000000UL

all: $(HEX)

clean:
    rm -f $(HEX) $(OUT) $(MAP) $(OBJECTS)

flash: $(HEX)
    avrdude $(AVRDUDE_FLAGS) -c $(PARTNO) -p $(MCU_AVRDUDE) -P $(DEVICE) -b $(BAUDRATE) -U flash:w:$(HEX)

$(HEX): $(OUT)
    $(OBJCOPY) -R .eeprom -O ihex $< $@

$(OUT): $(OBJECTS)
    $(CC) $(CFLAGS) -o $@ -Wl,-Map,$(MAP) $^
    @echo
    @$(SIZE) $@
    @echo

%.o: %.c $(HEADERS)
    $(CC) $(CFLAGS) -c -o $@ $<

%.pp: %.c
    $(CC) $(CFLAGS) -E -o $@ $<

%.ppo: %.c
    $(CC) $(CFLAGS) -E $<

With the Makefile in the same folder as your main.c just run:

make
make flash

And you should have you program running in the Arduino.

To know the pin mappings from the board to the actual ATMega2560 pins, you can check this useful resource.

I used to be under the impression that I had to be extra formal and maintain a proper etiquette when writing git commit messages. After all, my work flow mostly consists of hacking on a branch, merging all the commits into master and the pushing upstream.

Whenever I felt like committing I used to think: "Well, this doesn't really mark a milestone in anything. Why would it make sense to have it on the main branch as a commit for the future generations to see?"

Turns out I was doing it all wrong because I had yet to meet git cherry-pick and didn't know you could "mash" commits together.

So suppose you start working on my_working_branch.

* 6390118 (master) third commit  kirbuchi, 2 minutes ago
* 40a6dfc second commit  kirbuchi, 3 minutes ago
* 03b732e (HEAD, my_working_branch) first commit  kirbuchi, 4 minutes ago

After a harsh battle with the new feature you're trying to implement, your new branch won't probably look so pretty. As a matter of fact, depending on your temper or what kind of day you're having, it may look something like this, if you don't hold back:

* e2124ed (HEAD, my_working_branch) work you piece of shit  kirbuchi, 30 seconds ago
* 371d5c0 oh god, why?  kirbuchi, 79 seconds ago
* 60d176c now it's hopefully ok  kirbuchi, 1 minute ago
* c8c3ce3 another change  kirbuchi, 2 minutes ago
* f7fd2b5 some tweak  kirbuchi, 3 minutes ago
| * 6390118 (master) third commit  kirbuchi, 5 minutes ago
| * 40a6dfc second commit  kirbuchi, 6 minutes ago
|/  
* 03b732e first commit  kirbuchi, 7 minutes ago

Of course you don't want your coworkers to stop thinking you're a nice guy so you may do the following.

git checkout master
git cherry-pick -n ..my_working_branch

The -n options tells git not to merge all the commits on top of you current branch but instead to have their changes applied on top of you working tree. Then you can commit with a more appropriate message.

git commit -m "Implemented new feature X"

And have everything look nice and presentable:

* 83449fa (HEAD, master) Implemented new feature X  kirbuchi, 10 minutes ago
* 6390118 third commit  kirbuchi, 13 minutes ago
* 40a6dfc second commit  kirbuchi, 14 minutes ago
* 03b732e first commit  kirbuchi, 15 minutes ago

Having this in mind, I now see a commit sort of like a save on one of those old console emulators where you could save and load your progress immediately if you die or screw up.

Of course I still believe proper etiquette must be maintained when working with others and I don't want to end up on this site or getting yelled at by famous geeks.