Emacs: Cycling through workspaces in perspective mode
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
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
persp-next works and found this, which is pretty straightforward:
(defun persp-next ()
"Switch to next perspective (to the right)."
(persp-switch (nth (1+ (persp-curr-position))
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."
(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))))
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.
Using the Arduino Mega 2560 as a regular MCU with avrdude
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
rm -f $(HEX) $(OUT) $(MAP) $(OBJECTS)
avrdude $(AVRDUDE_FLAGS) -c $(PARTNO) -p $(MCU_AVRDUDE) -P $(DEVICE) -b $(BAUDRATE) -U flash:w:$(HEX)
$(OBJCOPY) -R .eeprom -O ihex $< $@
$(CC) $(CFLAGS) -o $@ -Wl,-Map,$(MAP) $^
%.o: %.c $(HEADERS)
$(CC) $(CFLAGS) -c -o $@ $<
$(CC) $(CFLAGS) -E -o $@ $<
$(CC) $(CFLAGS) -E $<
With the Makefile in the same folder as your
main.c just run:
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.
Cherry-picking for fun and profit
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
and didn't know you could "mash" commits together.
So suppose you start working on
* 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
-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.