Conkeror in the Debian NEW queue //at 21:39 //by abe

I already mentioned a few times in the blog that I’m working on a Debian package of the Conkeror web browser. And now, after a lot of fine-tuning (and I still further new ideas how to improve the package ;-) Conkeror is finally in the NEW queue and hopefully will hit unstable in a few days. (Update Thursday, 03-Jul-2008, 18:13 CEST: The package has been accepted by Jörg and should be included on most architectures in tonight’s updates.)

Those who could hardly await it can fetch Conkeror .debs from http://noone.org/debian/. The conkeror package itself is a non-architecture specific package (but needs xulrunner-1.9 to be available), and its small C-written helper program spawn-process-helper is available as package conkeror-spawn-process-helper for i386, amd64, sparc, alpha, powerpc, kfreebsd-i386 and kfreebsd-amd64. There are no backported packages for Etch available, though, since I don’t know of anyone yet, who has successfully backported xulrunner-1.9 to Etch.

Interestingly the interest in Conkeror seems to have risen in the Debian community independently of its Debian packaging. Luca Capello, who sponsored the upload of my Conkeror package, pointed me to two blog post on Planet Debian, written by people being fed up with Firefox 3 already and are looking for a more lean, but still Gecko based web browser: Decklin Foster is fed up with Firefox’ -eh- Iceweasel’s arrogance and MJ Ray is fed up with Firefox 3 and its SSL problems.

Since my previously favourited Gecko based web browser Kazehakase never became really stable but instead became slow and leaking memory (and therefore not much better than Firefox 2), I can imagine that it’s no more an candidate for people seaking for a lean and fast web browser.

Conkeror has some “strange” concepts of which the primary one is that it looks and feels like Emacs:

• The current location is shown in a status bar below the website, where Emacs usually shows buffer names. All input, even entering new URLs to go to, is done via the mini-buffer, an input line below the status bar.

• Instead of tabs it uses Emacs’ concept of buffers. So no tab bar clutter and though easy access to all currently open pages.

• It has no buttons, menu-bar or such. And except the status bar and mini-buffer, it uses the whole size of the window for the displayed web page. This is the main reason why I prefer Conkeror on the 7” EeePC: I don’t want to waste any pixels for buttons or menu bars and still have a fully functional web browser.

• It of course has Emacs alike keybindings (with a slight touch of Lynx). While this may seem awkward for the vi world (Hey, they have the vimperator^*, also in Debian since a few days!), as an Emacs user you just have to remember that you web browser now also expects to be treated like an Emacs. It just works:

  C-x C-c

  Exit Emacs -eh- Conkeror

  C-x C-f

  Open File -eh- web page in new buffer

  C-x C-b

  Change to some other tab -eh- buffer

  C-x C-v

  Replace web page in this buffer and use the current URL as start for entering the new one

  C-x 5 2

  Open new frame -eh- window

  C-x 5 0

  Close current frame -eh- window

  C-x k

  Close tab, -eh- kill buffer

  C-h i

  Documentation

  C-s

  Incremental search forward

  C-r

  Incremental search backward

  C-g

  Stop

  l

  Go back (Think info-mode)

  g

  Go to (Open web page in this buffer)

  (Hehe, I like the faces of vi users having read these keybindings and now wondering how to remember them. SCNR. Well, sometimes vi key bindings are a mystery to me, too. :-)

  There are of course many more and nearly all are the same as in Emacs, even the universal argument C-u and the M-x command-line are there. E.g. C-u g lets you open a web page in a new buffer, too.

• Conkeror also has very promising concept for following and copying links with the keyboard only. Opera is very inefficient here since you have to jump from link to link to get to the one you want. In Conkeror you just press f for following or c for copying links and then all links on the currently shown part of the page show a small number attached to it. Then you just enter the number (and additionally press enter if the number is ambigous) and the link is either opened or copied to the clipboard.

  A funny anecdote about how this concept grew over the time: Early versions of Conkeror (back in the days when it just was a Firefox externsion as vimperator) numbered all links on the page, not only the visible ones. On large pages with many links or buttons (e.g. my blog ;-), this took minutes to complete. The idea to just number the visible links is so simple and important – but someone first needed to have it. :-)

Footnotes

*) I just noticed that there is now also muttator, making Thunderbird look and behave like vim (and probably also mutt), too. Wonder into which e-mail client the Emacs community will convert Thunderbird. GNUS? RMAIL? VM? Wanderslust? What will it be called? Wunderbird? Thunderslust? (SCNRE ;-)

Is ikiwiki a Website Meta Language killer? //at 22:29 //by abe

On this year’s Chemitzer Linux-Tage (CLT, engl. “Chemnitz Linux Days’) I attended a few talks of which especially formorer’s ikiwiki talk was very interesting.

I attended his talk since I found out that ikiwiki is command line wiki compiler in contrary to the thousands of solely web based wikis out there. As a big fan of statically generated content this idea sounded very interesting to me.

But just having a short look at ikiwiki’s web page didn’t help to get started and it seemed as if I had not the right idea of how ikiwiki works to get started. So formorer’s talk seemed to be a good possibility to get an idea of how ikiwiki works without much effort.

During the talk I noticed that ikiwiki can many things I do with the Website Meta Language (WML), but can do some more things WML can’t do out of the box:

1. It’s not only a framework to generate web pages, it’s more like a content management system (CMS).
2. Versioning is intergal part of ikiwiki without reinventing the wheel: It works out of the box with — beyond others — Subversion, Git and Mercurical (Hg).

And when formorer showed that even Tobi Oetiker uses ikiwiki, I noticed that ikiwiki probably could be a WML killer, since I knew Tobi as a WML fan. And ikiwiki looks very appealing for the WML fan inside me, too…

OTOH: Intergrating WML as a backend to ikiwiki could be an interesting idea, though.

Hearing what kind of input files ikiwiki can process, I also got the idea of using hnb (Hierachical Notebook) files as input for ikiwiki. hnb files are already XML and so a conversion to XHTML shouldn’t be that hard.

But when searching the web for “ikiwiki hnb” I found the blog postings of a few people switching away from hnb, e.g. to vimoutliner. Since I’m an Emacs addict and don’t like vim very much (if I use a vi, I use nvi or elvis), I searched for “emacs hnb” and indeed found someone who switched from hnb to org-mode – of which I never heard before. Unfortunately org-mode doesn’t seem to be in Debian (Update 00:23: Yeah, yeah, I now know it’s included in emacs22, but emacs22 hasn’t made it into kfreebsd-i386 yet, so I didn’t notice. See the comments. :-) but I’ll play around with it a little bit. Unfortunately a first test wasn’t that promising. But we’ll see.

Now playing: Men at Work — Down Under