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