For some time I’ve relegated bs-show to the longer binding and now use Stephen Bach’s excellent Lusty Explorer which works really well when you know the name of the buffer and it’s fairly unique. However when you’ve been going a while it can get un-manageable with a large number of open buffers, especially if you’ve opened second copy of a file from another source tree. This is what I would use the old classic bs-show for.

A few days ago I discovered ibuffer-mode with it’s ibuffer-bs-show buffer navigator. Looking back through the Planet Emacsen history I can see it has been mentioned before and given it’s been in Emacs since version 22 I’m surprised I hadn’t cottoned on to it earlier.

One thing that might have put me off is the initial buffer list can be quite sparse. By default you only see buffers with files associated which misses out IRC, Edit with Emacs and *scratch* buffers. However hit “h” and you’ll see there are a plethora of quick keys for chaning the view. A quick “//” and all filters are removed and you can quickly filter by different criteria. To get the most out of the mode you’ll probably want to set up some custom filters (“/r<completing filter name”>) to make quickly switching to groups of buffers easy. I currently have “work”, “remote”, “irc” and “logs” as filters. You can filter by name as well as major-mode.

ibuffer-mode does have the concept of Filter Groups although I’m not sure what they add on top of having normal filters which as far as I can tell can be arbitrarily complex. It also has some quite handy sorting and selection modes e.g. “sv” – sort by last viewing time. Given the amount of space the wiki devotes to the topic I wish I’d re-examined my buffer switching habits sooner. The change is already paying dividends for my productivity.

Before I go I thought I’d put in a quick mention of Google+. There is growing community of fellow Emacs users starting to post on it. One thing that attracts me to Google+ over Facebook (too data-miney) and Twitter (too short) is the concept of “Circles”. It makes sharing geeky Emacs posts with people that might actually care easy while sparing them the flood of baby pictures I share with friends and family. If you’d like to follow me or my alter-ego please do mention Emacs in your profile or in a message so I can assign you to the correct circles.

Previously I had two sets of org notes. My personal set where sitting on my server which I could access via the terminal. I generally accessed this at home on the odd occasion when I was doing things like the annual round of insurance quote gathering. The second set was a fairly simple time sheet type affair that I was using at work to keep a vague track of where all my time was spent. The big missing part of this is when I’m on the move.

I’ve just recently upgraded my phone to the latest Galaxy Nexus which is a fine Google enabled device. I make no apologies for using Google’s calendering and shared document services. They work very well and importantly allow me to share things with my wife who doesn’t quite share my desire to run everything from a text editor. However for my personal task lists on the move and remembering what’s coming up at work it doesn’t quite cut it. Besides I like org-mode and I’d heard about MobileOrg so I endeavoured to set it up.

MobileOrg has been around some time for the iPhone but the mechanisms it uses for integrating with org-mode are fairly well documented. As a result there is a couple of Android implementations for it. Matthew Jone’s mobileorg-android was the first version I tried.

The original sync method for MobileOrg was to use a service like Dropbox to sync files. Given the history of Dropbox’s security I wasn’t about to move my files into the proprietary cloud. The alternative is to enable WebDAV on my web-server and therefor enable two way communication via HTTP. It was a little concerning to see self-signed SSL wasn’t supported as this does open up a potential attack vector on my machine. I’ve mitigated it a little by using digest authentication instead of basic-auth but I’d still prefer to be conducting these read-write operations over something more secure.

Initial results were a little underwhelming. After some messing around with the format of org-links I eventually got a basic outline summary up. Unfortunately I can’t seem to sync notes created on my phone to the server. This seems to be a Apache problem which I shall have to dig into later.

After perusing the market some more I noticed there is a new project in town. Konstantin’s MobileOrgNG was forked some time ago from Matthew’s code and on installing I found it looked an awful lot better. I’ve still be unable to post any locally added notes (due to previously mentioned Apache config issues). However it’s presentation is a lot slicker and it shows a lot of potential for being a good MobileOrg client.

I’m now stuck with a classic open source fork dilemma. The code bases look to have diverged enough that these two projects are essential going their own way. Looking at the two impact graphs it looks like they diverged around August 2011 and since then MobileOrgNG looks pretty much like a solo effort albeit with an impressive commit rate of new features.

So the questions for my readers. Which code base should I jump on? Has anyone got experience with the two different code bases and the reason they split? Are there any other Android clients for org-mode I should be looking at?

A big cosmetic change is a brand new settings page which looks less like a web-form from the early 90′s and more like part of Chrome. Alas I can take no credit for this but can thank Frank Kohlhepp’s fancy-settings library. In fact a lot of the credit should go to third party libraries like jQuery and of course the growing list of contributors who have submitted code for merging.

So the final changelog for 1.10 is:

Extension

* Ignore textareas marked as read only
* Don’t tag areas that are not visible
* General clean-up to use jQuery to find elements
* Explicit CSS for edit button to override page settings
* Handle editable DIV blocks (e.g. Google+)
* Optimise the finding of text areas for highly dynamic pages
* Revamp the settings page with “Fancy Settings”

edit-server.el

* Allow customisation of edit-server-default-major-mode
* Allow edit mode to be set by matched URL
* Tweak detection of MacOS X Emacsen
* Change behaviour of C-x C-s to save to kill-ring
* Persist the buffer-local variables beyond mode changes
* Setup keymap within defvar
* Clean-ups to code to be more idiomatic.

As regular readers of the non-emacs sections of my blog will be aware my recreational coding time is about to be severely curtailed. As it’s been a while since the last release and a number of new features have been added it would be nice to get some wider testing. I therefor am hoping to elicit the help of the Emacs community to check out the code and give the tires a bit of a kick before I push out the final release to “the cloud”. I’d rather not regress behaviour for the 1917 users who get Edit with Emacs from the Chrome store just before I disappear into a haze of nappies and parental responsibilities. The current changes over the last release are:

Extension

* Ignore textareas marked as read only
* Don’t tag areas that are not visible
* General clean-up to use jQuery to find elements
* Explicit CSS for edit button to override page settings
* Handle editable DIV blocks (e.g. Google+)
* Optimise the finding of text areas for highly dynamic pages

edit-server.el

* Allow customisation of edit-server-default-major-mode
* Allow edit mode to be set by matched URL
* Tweak detection of MacOS X Emacsen
* Change behaviour of C-x C-s to save to kill-ring

Setting up a clock page is fairly simple. It’s then just a case of C-c C-x C-i and C-c C-x C-o on the appropriate sub tasks. Dynamic blocks can then be added to your org-document to generate weekly, monthly or annual reports based on the clock lines in the document.

So far the results have been illuminating and certainly shows how optimistic I can be in predicting how much time I spend doing my core job hacking on the code. However one thing that is captured but hard to summarise is interruption cost. I’ve taken to switching task every-time I’m interrupted in person or by phone call (I’m not counting IM/IRC as it’s less disruptive). I can eyeball the raw data and see that some weeks are exceptionally bad for task switching. However what would useful is a break-down of mean and median clock lengths against each task to give some sort of indication of how much straight line hacking I’ve gotten done. I have a feeling the :formula and :formatter options could be used for this but I’ve been struggling to find any example. Does anyone do a similar analysis with their org-mode clock data?

UPDATED: fixed keystrokes.

 ;; Add site-lisp to search path
; 
; This is a work-around function for when I'm running bleeding 
; emacs from the source tree but still want Debian's developer 
; tools. I'd caution about having too many extra packages about that 
; have been merged into the source tree (cedet etc) lest it get 
; confused. 
(defun load-debian-site-lisp()
"Attempt to load Debian's site-lisp if it's there"
  (interactive)
  (when (and (not (member "/usr/share/emacs/site-lisp" load-path))
             (fboundp 'normal-top-level-add-subdirs-to-load-path))
	      (let* ((default-directory "/usr/share/emacs/site-lisp"))
      (normal-top-level-add-subdirs-to-load-path))))

(load-debian-site-lisp) 

Which seems to work well enough to give me my debian-changelog-mode back. However it’s still not seamless as I have to manually (require ‘debian-changelog-mode) before loading a changelog which forces the issue with local variables. I suspect I’ll have to replicate the boilerplate that /usr/share/emacs/site-lisp/debian-startup.el does but I can’t use because it doesn’t degrade gracefully if no debian-emacs-flavour is defined. Suggestions for making this behaviour neater would be useful….

My naming scheme for any repository is generally to add the version control extension to the directory. This is more for my benefit than emacs as it’s quite capable of working this out for itself in any given repo. However it turns out that Lusty was being a good emacs citizen and using the variable completion-ignored-extensions which included the pattern “.git/” and duly hiding my repo directories from completion. In fact there are a number of patterns in there which should probably be more specific. I wrote this to fix the problem:

(setq completion-ignored-extensions
      (mapcar '(lambda (ext)
                 (if (string-equal "/" (substring ext -1 nil))
                     (concat "^" ext)
                   ext)) completion-ignored-extensions))

It still seems a little ugly to me so given the last time I berated elisp’s style gained so many useful suggestions I’d welcome improvements.

v1.9

Extension

* Support for iterative editing (python server only currently)
* Add context menu while in text area box
* Fix reference to Alt-E, it’s actually Alt-Enter
* Trigger a DOM change() event when we update the text area

edit-server.el

* Actively encode responses as UTF-8
* Make edit-server-edit-mode a minor mode instead of a derived mode

Professionally I’ve been doing really well. The company I work for has had yet another record breaking year which has triggered my bonus again (although I don’t find out how much until I get back). It continues to grow in both revenue and size. I finally feel comfortable with the code base I’m working with. At the same time the ever growing feature list means I’ve still got plenty of interesting things to do with it. Although the internal code is proprietary to the company I’ve got a fairly wide latitude to work with FLOSS code and it makes a significant portion of the NMS product. Pretty much anything that I hack on that is useful to the wider community outside the application specific task is fed upstream which is good for both the company and the wider world.

Aside from my work based hacking 2010 was also the year I became a real open source project maintainer. I’ve been publishing code I write and use for a long time and have done maintenance work on some niche projects as well as contributing to other projects as normal. However at the start of 2010 I released Edit with Emacs to an unsuspecting world. It started as a simple exercise in learning some Chrome Javascript and kicking me to delve deeper into elisp coding. However since then it has grown to something that gets regular contributions and is used by over a thousand people. To quote Blur it gives me an enormous sense of well being

This year has also been an interesting year politically. While there is plenty of debate about the economics of some of the choices made by the coalition I’m personally fairly happy with the approach being taken given the fairly dire conditions they inherited. From my geek point of view it’s heartening to see the pre-election commitment that was made to open data seems to be being lived up to. I’m hoping the changes to openness will get embedded into the way government does business permanently.

The big thing that dwarfed all other things this year of course was getting married to the wonderful Fliss. Saving up all my holidays for the honeymoon meant we didn’t have many extended breaks and of course as the logistical tasks approached there was much running around and controlled panics. In the end everything went like a dream and the wedding itself was a blur of happy memories. It was a fantastic day and made all the better for all the friends and family that came along to share in the celebration. Getting married to Fliss is quite possibly the best thing I’ve ever done.

I do occasionally have pangs of guilt considering how lucky we have been especially when so many are struggling with the uncertainty of the economic situation and the stress that causes. All I can do is wish the best of lucky to everyone for the next year. I hope it exceeds the positive expectations and under-performs on the negative ones!

The rest is as follows:

Ryszard Szopa (1):
      Allow the server to send correct Unicode to Chrome.

gfxmonk (4):
      trigger a DOM change() event when textarea content has changed
      clarify that the shortcut key is Enter, not "E"
      only re-request edit when "x-open" header is "true", not merely present
      Made indentation consistent across all source files