Efficient wiki editing with w3m and vim

~ Don Stewart ~ Leave a comment

I find I spend quite some time editing wiki pages, such as the Haskell.org wiki. However, browser-based editing leaves a lot to be desired, generally making the editing process more inefficient and difficult than it needs to be. I suspect that these inefficiencies hamper contributions, especially in longer texts. The main problem with wiki editing is the browser-based editor forms aren’t proper editors, so you’re just wasting your time using them.

Key missing features are:

  • Syntax highlighting
  • Regular expressions substitutions
  • Spell checking
  • Programming tool support (particular for a PL wiki like Haskell.org)

We can fill these holes, and improve efficiency, by using the text-based browser w3m along with your favourite text editor, which for me is Vim. w3m is a simple, fast, terminal browser, which uses an external editor by default, for editing online forms.

Syntax highlighting for wiki files, with embedded Haskell, and Vim is available here. Save this to your ~/.vim/syntax directory, and enable it dynamically when editing online with :setf haskellwiki.

Using your favourite editor from w3m is as simple as setting: editor: vim -c "setf haskellwiki" in the w3m configuration screen (type o in w3m to bring this up). This also enables syntax highlighting by default, including Haskell fragments embedded in “<haskell>” tags.

And of course, vim being vim, you have access to unix tools via the shell (such as aspell), programming tools like lambdabot (pointfree refactoring of wiki code, anyone?) and more.

More details on text editor support for wiki editing, from a variety of browsers. Thanks to jgrimes for advice on this.

Finally, for the future, I’d like to investigate a generic mechanism for exporting wiki pages to a local revision control system, such as darcs. For large wiki subsections I work on, I currently save files locally in a new darcs repository, edit them, then upload the subsection in a single pass when complete. This is tedious — power users should always have a revision control back end to the wiki, for pushing and pulling changes directly. This is the way this blog is published: developed in a local darcs repository, and then pushed to a public repository, which blosxom then renders. Ideally, preparing wiki articles too should involve only the editor and a revision control system, for publishing.

More default defaults

~ Don Stewart ~ Leave a comment

In normal Haskell you can use what is possibly the most obscure Haskell98 feature, the default keyword, to modify how type defaulting works, and resolve ambiguities — but only for numeric classes. The result is less type signatures, as below:

default(Double)

main = print $ 2 + 1

In ghci, this defaulting has been extended to the Eq, Ord and Show classes, so we can write, in ghci:

> reverse []
[]

and ghci will find the right Show instance. Now, in lambdabot, we can evaluate user’s code in the irc channel, but often the user has to add extra types to have the right Show instance found:

dons:: > reverse []
lambdabot:: Add a type signature
dons:: > reverse [] :: [()]
lambdabot:: []

This is annoying. What would be really nice is if the defaulting mechanism used by ghci was available to userland Haskell, by a -fglasgow-extension of the default keyword mechanism.

Update Simon has now kindly added a new flag to GHC, “-fextended-default-rules”, which does exactly this. Lambdabot won’t be second class anymore :)