emacs on android - part one on [2013-06-11 Tue 11:56]

I have been on a difficult journey to get emacs to run acceptably on my android phone. The native port is about 95% of the way there. The first challenge was getting dired to work. Using 'ls-lisp as described in this issue solved that problem.

The second challenge was getting tramp to work. My ultimate goal is to be able to edit files remotely so tramp seemed to be the best option. Tramp failed with some error about not being able to execute /bin/sh.

To work around this, I figured I could just run a linux emulator and go completely native. Down the rabbit hole I went. I installed limbo and spent many hours trying to find the right distro that would run reasonably well. Damn small linux ran OK (sluggish, but tolerable) but didn't have a recent emacs build and was quite large. My next attempt was Tinycore. It also didn't have a recent emacs build so I set off to build it. It took about 32 hours to build under the emulator which was running at around 100 bogomips. Emacs launched! Success. Still, very slow under X.

I then continued down the rabbit hole. I figured I should try running it in a terminal and bypass X altogether. Turns out that the default terminal could only handle 8 bit colors and required passing boot parameters to get a decent resolution. Workable, but still not ideal.

The next stop on the journey was evaulating fbterm and fbpad for framebuffer terminals. If I could get that working, presumably I could have 256 colors and a high resolution display without needing the overhead of X11. Turns out that I needed to compile fontconfig and freetype. Both are relatively large and I was afraid would take a long time to build and a long time to error out and find out that I needed something else.

It hit me that I could build on a virtual image running on my desktop and then transfer the files over. I went down that path and successfully compiled both fbpad and fbterm. Both worked reasonably well. fbpad stole keys that emacs uses (ctrl and alt) which eliminated that from the running after evaluating what it would take to customize it. Still, neat, small software.

Fbterm was the winner. I finally got fbterm running. Sidebar I later realized that there is a tinycore package for it already. D'oh! With fbterm running and tmux, I had a functional emacs installation running on my phone. Again, slow, but functional. I fired up tramp and was able to edit this blog org phone. Each key took about a second to register as I typed. Not good.

Instead of throwing up the flag, I set out to optimize the boot time of my installation. I don't know why. Perhaps I thought I would tolerate the slowness of typing if I could get the darn thing to boot in less than 10 minutes.

I set out to understand the remastering process for tinycore. The majority of the boot time was stuck in loading extensions - tinycore's terminology for applications that run in loop devices. To get emacs running, I needed to load tmux, fbterm, which then needed to load freetype, fontconfig and then some X libraries for some reason. Too slow! I could remaster the whole thing so it was part of the base image instead of loading as an extension each time it booted.

Research took me to this blog which explained a process that worked relatively well for me. Long story short, I basically just unsquashed my optional packages to the root directory of my new image. It took a few times because the whole GCC extension and it's 20 or so subextensions caused my ram image to be too large so it wouldn't boot. I had to trim it back down to only what I needed to run emacs and fbterm.

Finally I got the boot time to about 5 minutes. Twice as fast. That challenge was satisfied with as much effort as I was willing to put in at this point. Emacs was still too slow to effectively write.

I decided to shelve the project and get back to real work. The next post will describe how I switched directions and used kbox2 instead.

Prev: emacs on android - jasspa  Next: Posting from qemu on my phone under emacs