Finally ported CodeMirror syntax engine to bespin

I have written before about my attempt to port the CodeMirror syntax highlight engine to bespin. I got it mostly working now (for Javascript, HTML, CSS, PHP and even all these languags mixed together as in PHP) and have submitted an initial patch for review.

The port required quite a few structural changes of the code because, on bespin the syntax engine is running in a background thread if webworkers are available (FF 3.1beta, Safari 4beta, Webkit nightly) or gears is installed, otherwise it is still running asynchronous, triggered by a Javascript setTimeout() with value 0. This all has only been possible thanks to the groundbreaking work of Malte Ubl.

So if you wanna try that patch out today, you need of course a local installation of bespin, then apply the patch and use the command-line to enable / disable the syntax engine:

set syntax2 on / set syntax2 off

And don't expect it to be not even near as fast as the default engine. It is just an initial port, caching and other tricks to make it fast are not enabled or implemented yet.

Bespin, Mercurial and keeping your patch up-todate

While hacking on bespin I experimented some of the possible ways to keep a patch in sync with tip (this is how they call "trunk" in hg land).

Just cloning the repo for developing the patch

this is the easiest, and seems quite popular. Unfortunately you are switching physical directories when you switch between clones, and in the case of bespin, where running server-instances are tied to a physical directory, it requires either a smart approach for running the instances in parallel or easily shutting down one and starting up he other. And if you are working on different unrelated patches, it can get quite messy to do manual merges when tip changes. To sum up, easy to get started with, but lots of disadvantages.

Using branches

Branches are easy to create and easy to switch between them and they have one big advantage compared to cloning: You stay on the same physical directory if you switch branches. However, the pain of manual merges when tip changes seemed to me even worse than with cloning.

Using queues extension

this is currently my preferred way. With queues extension you have always a clean tip, can develop patches, apply them, remove them, apply /remove patch-sets and easily change the order of the patches in the set. Updating tip is as easy as:

hg qrefresh # update current patch with local changes
hg qpop -a # remove all patches
hg pull
hg update
hg qpush -a # apply all patches

What I haven't figured out yet is how to use bundles with queues extensions.

Update:
By enabling rebase extension, rebasing with tip got even easier. The lines above got reduced now to:

hg qrefresh # update current patch with local changes
hg pull --rebase

Update II:
Lately I just push my local repo with applied MQ patches to my personal public repo at bitbucket, with the purpose of facilitating the pull of my patches.