One of the things I've always wanted in a portable computer is the ability to run Emacs. The main reason is that since 2005 or so, my whole life has been run in org-mode, and, slightly before that, in howm. So, of course, when I got a low-end Android tablet, an Archos 70, of course, I...didn't install Emacs on it. As EmacsWiki implies, there's no perfectly obvious way to do so. And, there's MobileOrg-Android. When I first got my tablet, MobileOrg-Android was pretty bad. But it got better. Today, it's got a great user interface, syncing is fast and generally reliable, and there's an active core group of developers who are constantly adding features and contributing back to org-mode itself.

But...after quite a bit of trying, I still haven't made the MobileOrg workflow work for me. I keep my org files in a Mercurial repository on my home machine, and carry a clone with me. I run org-mobile-push and org-mobile-pull from the home repository, which requires it to be up to date, which usually can be done without manual intervention, but not always. And both pushing and pulling can make changes, which have to be committed. And you really have to sync on the mobile device twice: once before you push/pull, and once after, if you want the desired effect of pushing all your changes and captures to the repository, and having them all reflected on your device. The MobileOrg workflow is based on the idea that your mobile device doesn't have the horsepower to compute agendas on the fly. But is that true these days? I'll return to that issue later.

After seeing that some people had successfully run an Ubuntu user environment in a chrooted loopback filesystem on a similar tablet, I decided to try to get my Emacs that way. It didn't exactly work out right a way, and it took me quite a while to make time for the yak-shaving involved. Finally, I did, but with my preferred GNU/Linux distribution, Fedora.

Overview (the short version, aka tl;dr)

My sdcard is formatted ext3, and has the Fedora 13 rootfs unpacked into it. From a root prompt in ConnectBot, I bind-mount some required special filesystems under Fedora's root, then chroot into it, and start sshd. Then I can ssh into localhost with ConnectBot and run Emacs (and other things).

Longer version

Don't take this as a step-by-step instruction guide. What works and doesn't work on my device is likely to be quite different from what works and doesn't work on yours (unless yours is an Archos Gen8). This is really more to give you an idea of the kind of yak-shaving involved in getting this working.

First I rooted my tablet. I would have done this even if I weren't planning on running Emacs. For reference, the tablet is an Archos 70, running the latest version of the stock (Froyo) firmware, with a rooted initramfs.

Then, I tried installing the Ubuntu loopback images mentioned above. This didn't work for me, because the stock Archos kernel doesn't include the loop device, and for some reason, even when I built custom kernels with the loop device enabled, I couldn't get it to work.

Fortunately, my device has a microSD card slot, which is above and beyond the internal storage that the Archos firmware treats as an sdcard for the purposes of App2SD and so forth. I formatted a card as ext3, and tried to unpack the Ubuntu image onto it. This should have worked, but for some reason, my tablet didn't like having so much data pushed onto it over USB, and I lost the enthusiasm I needed to work on it.

Later, I unpacked the Fedora 14 ARM root filesystem more successfully, and tried chrooting into it, only to find that my kernel was too old for the version of glibc in Fedora 14. This also tragically sapped my motivation, causing me to stop working on it again for a while.

When I got another round tuit, I started with the Fedora 13 ARM root filesystem, and it worked pretty straightforwardly. This is what I did:

# umount /mnt/storage/sdcard
# mount -o noatime,nodiratime /dev/block/mmcblk2p1 /mnt/storage/sdcard

The sdcard is mounted with the options nodev,noexec,fmode=0666, and several other options that would make running it as the root filesystem of a normal linux slightly inconvenient. Some of the other parameters could be reset with mount -o remount,blah,noblah, but there doesn't seem to be a way to do that for fmode and dmode, so unmount and remount it is.

# cd /mnt/storage/sdcard/fedora
# mount --bind /dev dev
# mount --bind /dev/pts dev/pts
# mount --bind /proc proc
# mount --bind /sys sys

Now mount the various special filesystems that Fedora is going to need, that are provided by the kernel.

# chroot . /bin/bash -
# service sshd start

Now chroot into the Fedora environment, and start sshd. I've omitted some other stuff, like setting a (new?) password on the root account, and so forth. Technically, even starting sshd isn't necessary. You can just chroot into Fedora and run what you want to. Having sshd running makes it easier to reconnect to the Fedora environment without having to go through the process of cd'ing and chrooting to the Fedora directory.

From here on out, it's just installing stuff with yum. I've tried to avoid installing anything except what I particularly need.

# yum install -y emacs-nox git mercurial aspell aspell-en \
  diffutils patch man screen

What works

• Installing things with yum!

  There are things in the Fedora repositories that aren't supported on ARM, but I haven't had cause to install them yet.

• Emacs!

  Fedora 13 had Emacs 23.2.1, which is not exactly the latest and greatest, but it's not old enough to cause serious compatibility problems, either. I used hg to pull in my emacs startup code from my desktop, then created a mobile branch to strip it down and remove features I wouldn't be using, and to change paths to work with my mobile setup. Everything works as expected.

  Emacs startup is surprisingly snappy. I had slower emacs startup times on my desktop as recently as 5 or 6 years ago, and this isn't exactly a fast tablet.

  You might think it would be hard to use Emacs with a mobile keyboard, but Hacker's Keyboard takes care of that, by and large. It's still an onscreen keyboard, but it's an onscreen keyboard with all the keys you'd expect on a standard PC keyboard.

  Color themes work, as long as they would work under xterm-256color. Sorry for not including a nice one in the screenshots, but those were taken right after I got emacs running.

• Org-mode!

  This was where I had some concerns going in. The design of org-mobile was premised on the idea that mobile devices didn't have enough oomph to generate agendas on the fly, so emacs pushes pre-generated agendas. I have fairly large org-mode files. They'd be smaller if I archived to file more often, but I don't. So, is emacs on my tablet able to generate my agendas?

  The answer is yes, mostly. The first time I run org-agenda, emacs spends a very long time reading in my org-mode files; I suspect that the slow sdcard I'm running this from may be part of the problem. The first time, it was 30s, but similar 'cold' agenda startups have been around 10s since then. Subsequently, however, the agendas are generated perfectly quickly.

  All in all, my orgmode workflow works perfectly on the tablet, with the exception that hg tries to use vimdiff to do merges, for some reason!

  Also, one other issue is that since I am using emacs in a (local) terminal window, I have to use the alternate tty keys.

What doesn't work well

• Writing a lot.

  This is not exactly a surprise. Unless I go to another machine and ssh into my tablet (and what would be the point?), I'm constrained to use the onscreen keyboard. And not only that, it's worse trying to write with the onscreen keyboard in a regular Android app, because the predictive text is not active in ConnectBot.

  If I had a small hardware keyboard, I'd be more inclined to do actual writing on this setup.

  Another alternative is to let Emacs do the text completion, using either Predictive Mode or auto-complete. However, while both of those do prose completion fairly well (different strengths), neither does autocorrection, which is just as important with a soft keyboard.

• Leaving an Emacs session running all the time

  I'm used to never exiting Emacs. On my desktop/home-server machine, Emacs is started for me by systemd, which runs it with --daemon, and restarts it if it should ever crash. On my tablet, I started out by running it under screen, and switching back to it as needed. It turns out that this is fine, as long as I want to stay in the Fedora environment, but it doesn't leave enough memory for my usual set of Android apps to perform normally.

Conclusion

I haven't tried the next logical step, which would be to install Xvnc and its dependencies, and to run a local X session, to be displayed in an Android VNC client. I may not do so, because it looks like the keyboard situation in the main free Android VNC clients is not much better (if at all) than in the terminal, in terms of having the full set of keysyms available. And it is worse, in that in ConnectBot, Emacs's screen gets resized to accommodate the soft keyboard, whereas in VNC, the soft keyboard sits on top of part of the display area, which is not resized.

On the whole I'm happy with this experiment. I don't think it will replace my use of Jota for note taking, because of the text auto-completion and auto-correction issue. I'm not sure whether it will completely replace MobileOrg for me. I'm enjoying finding out.

I use Instapaper to push articles that would otherwise cut into my productive time into my less productive time: adding them from my browser, syncing with iPaper once or twice a day, and reading mostly in the evenings. For saving articles, I mostly use the Firefox add-on Instaright, which is handy because I can add links without following them. Most of the articles I save for later come from Google Reader, which I use mainly from Firefox, so that works well. What didn't work so well was my other main source of linkspam: identi.ca. I use identica-mode for my microblogging needs, so saving a link from identi.ca means a trip from emacs -> follow link to dent or site in Firefox -> Instaright. Obviously this is far too much opportunity to be tempted to read the article now rather than later, so I wrote an Instapaper client for Emacs.

The code is on bitbucket, and the instructions for using it are in the source header. It should be fairly self-explanatory. It saves URLs to your Instapaper account, and can get them either manually, by url-at-point, or, if you have w3m installed, from the current w3m page's URL or selected link. It doesn't provide any services for reading from Instapaper (offline or otherwise), and because of the terms of service on the official API and my lack of desire to do screen-scraping in Emacs Lisp, I don't plan on adding any. A combination of w3m and wwwoffle or polipo is probably your best bet if you need to read Instapaper in Emacs.

Edited to add: Naturally, when I released this, it contained a significant bug, to whit: due to changes in url.el, it only worked in Emacs 24. This has been fixed, though if you byte-compile it under Emacs <= 23, you will get a compile warning.

(add-hook \'identica-new-dents-hook
  (lambda nil
    (let ((n identica-new-dents-count))
      (todochiku-message \"Emacs Identica-mode New dents\"
                         (format \"You have %d new dent%s.\" n (if (> n 1) \"s\" \"\"))
                         (todochiku-icon \'social)))))

The advantage of using todochiku here is that you can let it handle talking to different notification systems (KDE vs. Gnome vs.Growl on MacOS vs Snarl on MS Windows), and have the same configuration everywhere.

Anyway, having fixed the font-locking issue, I've released bbcode-mode.el at bitbucket. In the process of releasing it, I searched for other bbcode modes to make sure I wasn't taking a name that was in use. It turns out that in the meantime while I wasn't releasing my bbcode mode, Xah Lee released another, xbbcode-mode. The two modes are rather different in design, so depending on your tastes, you might reasonably prefer either one or the other.

A side note: I wish bitbucket supported org-mode README files like github does.

Problems fixed:

• Had to reinstall lots of python libraries (had been built for 2.5, needed in 2.6) in order to get my websites to work. This was expected, though more packages were affected than I had expected.
• I had quite a few problems merging my old dovecot and postfix config files with the new ones, which resulted in the household not getting any mail for a few days. This was mostly my fault, though.
• Any sound played through pulseaudio was accompanied by a horrifying hissing noise except when the volume was at a single specific value. This turned out to be a problem with my sound device's ALSA driver and the "glitch-free" playback in pulseaudio. This is despite the fact that I have snd_via82xx, which is supposed to work. Changing pulseaudio's settings to add 'tsched=0' to anything that might load a hardware module solved it, but not until after a reboot. Probably an old pulseaudio process was hanging around from one or another user and keeping the old settings active.
• Gnome menus have old legacy things in them that they're not supposed to. I have to fix this with every dist-upgrade.

Not fixed yet

• Old VMWare doesn't work with the new kernel. On the laptop, which runs Ubuntu, I'd already run into this and upgraded VMWare to solve it. I'll have to do this here in the next week or so.
• Some of my policy settings (like letting sound continue playing when you switch users) have been lost, and since there is no longer any admin GUI for PolicyKit, there's no obvious way to fix this. I find this annoying, because my audio is played by mpd, the whole point of which is to play music when run as someone other than the active logged-in user. Adding some group memberships may fix it... have to see after restarting some services.

Conclusions

Fedora 12 seems nicely put together, and the upgrade was, though not the smoothest, smoother than many others I've gone through in the past.

This little code snippet fixes that. I'm not sure it's ideal in all ways. But it works for me currently.

(eval-after-load "w3m"
  '(progn
     (defun jfm/open-url-dwim (&optional url)
       (interactive)
       (if (equal browse-url-browser-function 'w3m-browse-url)
           (w3m-browse-url url)
         (if (equal (face-at-point) 'w3m-anchor-face)
             (w3m-view-url-with-external-browser url)
           (browse-url url))))
     (define-key gnus-article-mode-map (kbd "<return>") 'jfm/open-url-dwim)))

After my daughter was born, I needed to use it to show baby pictures to our family, so I had the motivation to at least fix stockphoto up to work with a current Django release. This is done; it mainly involved fixing up the model code, switching to forms from oldforms, fixing up the URLs, and fixing zipfile import to work with the new upload API. I have put the fixed code on bitbucket. If you pull from tip at that repository, or download a snapshot of tip from the downloads page, you will have a stockphoto package that works on Django 1.0.

This isn't quite a release though; it needs a few cleanups before I can push out an 0.3 release:

1. Update documentation
2. Since there were some small model changes, I need to provide a way of migrating from 0.2.1. I am leaning towards South for providing this.
3. Remove dead code

There won't be any new features in stockphoto 0.3 except for non-browseable galleries (which is already in bitbucket, since I wanted it for my daughter's site). I'm tentatively planning a 0.4 release that will have the features originally intended (since so many years ago) for 0.3, plus some suggested to me in email.

If you're interested in using stockphoto, please follow it on bitbucket, and send me any patches you find useful.

Now thank your lucky stars I didn't post the lines one at a time as article titles to get them to show up one-by-one in Planet Emacsen.

The script itself is here. I recommend that you install it somewhere on your PYTHONPATH. This is because command-line argument handling is very dodgy on w32, particularly when the program is interpreted, the interpreter is a native w32 program (not cygwin), and you may be calling it from a cygwin program (such as cygwin bash). More details on installing it and its limitations on its own page.

Integrating it into anything: use the following elisp code:

(defvar w32-windows-search-program
  \"python.exe -m DesktopSearch\"
  \"Command to pass a search string to Windows Search.
Will be split on spaces to pass to start-process.\")

(defvar anything-c-source-w32-windows-search
  \'((name . \"Windows Search\")
    (candidates . (lambda ()
                    (apply \'start-process \"w32-windows-search-process\" nil
                           (append
                            (split-string w32-windows-search-program)
                            (list anything-pattern)))))
    (type . file)
    (requires-pattern . 3)
    (delayed))
  \"Source for retrieving files matching the current input pattern
with windows desktop search.\")

The given value for w32-windows-search-program depends on DesktopSearch.py being in your PYTHONPATH. With the above in your .emacs, you can add the source it provides (anything-c-source-w32-windows-search) to anything-sources just like any other anything source.

This generally works well enough for my needs. Hopefully it will be useful to other people using emacs on w32.

Here's where the hack comes in. One of the actions you can perform on files is 'open with default command'. The catch: this is not implemented on W32, which I have to use at work. On unix and MacOS, it this action is implemented by calling an external program --- 'xdg-start' on unix, or 'open' on Mac-OS --- with the filename as an argument. There is no equivalent command on W32 -- the closest is the cmd.exe shell internal 'start'. But because 'start' is a cmd internal, it is hard to call from emacs; the quoting may be badly messed up, for example, depending on whether you use cmd.exe or cygwin sh as your shell, etc. But here's a better approach: leave it up to emacs. Emacs on W32 has a function 'w32-shell-execute' that works like cmd.exe's 'start' internal.

The code to integrate this is now added to anything-config.el, a package of sample configurations for Anything. I'm now co-maintaining anything-config.el.

The practical upshot of this is that I can use 'anything' to find my playlist files while in emacs, and start them with Windows Media Player. Now if only Windows Desktop Search let you get text-mode search results back, or if there were a version of Tracker for W32...

It's nice that Chrome has Incognito Mode. But how incognito is it when your network admin can monitor the content of your traffic? Wouldn't it be nice to be able to switch your network traffic to a secure channel – like an SSH tunnel to an http proxy under your control, or TOR?

Firefox has the 'Distrust' extension that provides the same protections as Chrome's Incognito Mode (other than the v. stylish fedora-wearing spy logo). And it also has your choice of extensions that let you switch proxies without going into the depths of the advanced settings menu: QuickProxy, SwitchProxy, FoxyProxy, and several TOR-specific extensions. Now if only Distrust had a setting that let one turn on their proxy for the duration of the Distrust session…

In Firefox, I have the Mouseless Browsing plugin installed, which lets me hit a key to label links with numbers, then type the number to follow the link. But even without MLB, you can browse mouselessly with the typeahead search – type '/', then start typing the text of the link, and when the link you want is highlighted, hit enter. In Chrome, you can only tab between links, not jump directly to the one you want (even with the search function). That is, you can search for link text, and it will highlight it, but you cannot then select the link without tabbing to it from the beginning.

2004/03/12 10:02 EST (via web):

About the "directing" vs. "enabling" approach, you wrote: "Both approaches are reasonable and neither is wrong. I have been in both situations; for example, trying to prevent interns from ignoring or even actively circumventing coding style guidelines (where more "direction" was required), and on the other hand being frustrated by the loss of productivity that comes from being forced to conform to constraints that I wouldn't have violated anyway [...]?".

It is interesting that you justified the "directing" approach with an example about directing others, and the "enabling" approach with an example about enabling yourself. Don't take this as a negative critique - I did the same when I tried to come up with examples of directing/enabling.

I tend to think that others should be directed, and I should be enabled. I worked for teams whose job was developing software methodologies and the relative supporting tools for the rest of their Company. Except that, of course, they flat-out refused to apply the (directing, strict) methodologies that they were developing to their own methodology-building project. To me, that shows how much in software development is about our own relationships and fears. We still have an awful lot to learn from sociology and antropology - and maybe, oriental philosophies.

Paolo Perrotta Bologna, Italy

I prefer "enabling" approaches everywhere, and agree with the statement that if you have someone who can't handle an enabling approach, they don't need directing, they need training. But many people (especially in corporate IT) would argue that this places too high a bar on experience and education for programmers. Still, I'd rather see enabling done technologically, and where direction is needed, see it done socially.

I'll be opening development on stockphoto 0.3 once I decide the best way to host a public version control repository (Google code vs. Savannah, vs self-hosting). The pre-0.3 branch will include new features, some of which are listed as to-dos in the current README.

I've recommended Hushmail to friends and neighbors in the past, as a way of easing them into the idea of using encrypted email on a regular basis. When I read this news, I felt I had to email people that I had recommended it to, to let them know about the weakness. Hushmail could set up their systems so that they never store a passphrase except in volatile memory, and so that they never store plaintext of messages. But you'd have to trust them on that, and a court order could still mandate that they store them, and not tell you they were doing it.

The best thing would be for everyone to use GNU Privacy Guard on their own computer. But it can be hard to set up, especially for Windows users (though if you're running Windows, you have bigger security problems), and your correspondents have to all be using GnuPG or OpenPGP, too. This is a big barrier to entry, and even though I'm set up to use it, very little of my total volume of email is routinely encrypted as I'd like it to be. There is also the problem of people without their own computers, who must use shared resources such as public library computers. Hushmail appeared to be the most viable option for them.

If you are interested in using GnuPG, you might look into the Enigmail plugin for Mozilla Thunderbird as a cross-platform solution. If you're already using Linux, Evolution groupware provides easy-to-use GnuPG support. If you want to send me encrypted email, you can download my public key, the fingerprint of which is C046 0E26 8103 ABA1 68B1 D6E7 A991 E701 91DF 7DDD.

Basically, I'm amazed by iPhone users' collective reaction to the bricking of their phones the same way I'm amazed by the reaction on Daily Kos to the Andrew Meyers tasing. In both cases, the affected community is mostly reacting with "hurt us more! We deserve it!".

Contrast the OpenMoko project. Install whatever you want across a whole range of supported phones. Switch phones keeping the software you installed.

How are you going to hack your life if you can't even hack your gizmos?