[xmonad] Extensible programs & defaults: the Gosling Emacs experience

[Gwern Branwen]

So, I happened to be reading a PhD thesis on exokernels, when I came across a reference. The context was that an exokernel is a maximally minimalistic operating system kernel; the kernel solely divides up resources among running programs. The programs get all other abstractions and standard OS services by linking in customized libraries, 'libOSes' as the developers put it. The point was that while an exokernel is designed so that any program can customize the operating system as much as possible, the defaults are still profoundly important, and the authors mentioned an Emacs retrospective which covered that.

"UNIX Emacs: A Retrospective. Lessons for Flexible System Design" (by Gosling & Borenstein).

I managed to get a copy, and I found some of it very instructive reading. Indeed, I find it instructive to look at various xmonad.hses after reading some excerpts:

"The one point on which nearly everyone seems to agree is that the best thing
about UNIX Emacs is that mlisp exists. No one even suggested that Emacs would be
better without the powerful facility for extension and customization, although
it is clear that such facilities, if abused, can create an environment that
changes so radically from day to day as to be unusable for most people."

"The integration of powerful editing facilities with a full-fledged programming
language seems unquestionably useful, though it remains a matter of some debate
whether this combination is best achieved by an extension language for a text
editor or by implementing the text editor as a subroutine library in an existing
programming language."

"The key principle is that there is *simple syntax for simple operations*. This
does not mean that a more complex syntax should not be available for more
complex operations, only that the complexity should not be forced on the
programmer in a simple context."

"It didn't have to be that way. In the development of Emacs, it was far too easy
to say that, since the support for the kind of basic interface was entirely
customizable, it wasn't important to devote a lot of attention to getting the
default interface to be correct. After all, anyone who didn't like the interface
could change it. What this attitude ignored, however, was the old rule our
mothers used to teach us about the lasting value of first impressions. Many
people tried Emacs, couldn't stand the basic interface, and went back to their
old standard editors, such as the vi editor on UNIX."

"It is worth noting that this happened despite the fact that several people,
independently, implemented more or less complete vi emulation packages for Emacs
in mlisp. It seems that even if a package existed that was an absolutely perfect
simulation of vi, most of the people who prefer vi to Emacs would stick with the
clearly less powerful vi. While this is in part due to the smaller size of vi,
it is also attributable to the unacceptable difficulty, in the minds of such
people, of having to learn how to turn the vi emulation package on in the first
place."

"The clear lesson to be learned from this is that, while flexibility in such a
system is indeed essential, great care must be paid to get the default
behaviours to be simple and natural, and to provide very clear and simple ways
to use a carefully chosen small set of the most commonly desired
customizations. It may be, organizationally, that the people who build the
flexible tools are not necessarily the right people to figure out which are the
correct defaults and 'standard options'. The process of making such choices
probably requires serious observation of users, or even controlled experiments,
to compare possible system configurations."

-----

I'm not sure how well XMonad works on the above criteria. It seems to me that there are a number of things which could be improved.

For example, one of the most common changes is to switch the modifier from Alt to Win, for the simple reason that stealing Alt renders many programs nearly unusable. The arguments I've seen is that we should follow dwm tradition, and that we have no guarantee that Win is mapped to a real key, but is it really impossible for us to, say, autodetect whether Win is usable and only fallback to Alt? Or perhaps on running XMonad the first time with a xmonad.hs, there could be a prompt. Or... there are many ways we could tackle this issue.

Another example: some function usages are copied all over the place. How many configurations have a line that looks like:

>                         , keys = \c -> myKeys c `M.union` keys defaultConfig c

Yes, it's neat that we can use basic Data.Map functions to union the default and custom keymaps (with the implication we can be flexible and combine them any other way we like), but it strikes me as wrong to have a relatively opaque task repeated time and again. Why don't we have a helper function such that we could write instead:

>                        , keys = overrideDefaultWith myKeys

Or if one is setting ManageHooks. Sure, one *could* write

>    , className =? "Firefox" --> doF (W.shift "web")

2, 3, 4, 6, or however many different entries one has in one's ManageHooks. But wouldn't a helper function be warranted so one could write:

>   , shiftClassToWS "Firefox" "web"

For that matter, am I the only one who wants to be able to unfloat windows in ManageHook? Leaving aside how there is no actual unfloat function, I was eventually able, thanks to #xmonad, to write in my xmonad.hs:

>  className =? "defcon.bin.x86" --> ask >>= doF . W.sink

But heck, do I understand that? Would someone else have any idea what that means? I mean, we're got 4 operators in there, 3 unusual functions (ask isn't even an xmonad function, it's from the State monad. I think. It seems a little much to expect customizers to understand monads, and the State monad, just to do a basic thing like 'unfloat an application when it opens').

------

In short, perhaps a goal for 0.9 could be to make customizing XMonad easier on the xmonad.hs level.

I think a second goal would be to change defaults in the XMonad core, and to perhaps add in some extensions by default - but that's an entirely other discussion. I'm not sure how people would react if I suggested making SmartBorders the default for the fullscreen layout. :)

--
gwern
Echelon Herald Islamic VHF CTP BATF POCSAG MDA USCG burhop
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://www.haskell.org/pipermail/xmonad/attachments/20080730/dd2f6eae/attachment-0001.bin