May 2009 - xmonad - Haskell.org

Emacs 23, Speedbar, XMonad 0.8.1, Wrong Window Focused
by aditya siram 05 May '09

05 May '09

Hi all, I am currently having a problem with XMonad correctly switching focus from the Speedbar ( in File mode ) and the editing window. Choosing a file in the Speedbar loads that file into the editing window but XMonad's focus stays in the speedbar. Surprisingly I can edit and navigate the file just fine in the editing window ( meaning all my keypress events are caught by the editing window ), but XMonad still thinks that the Speedbar is the master window. If I now switch layouts the Speedbar truly becomes the master window, also the red border stays with the Speedbar while I am typing in the editing window. I then have to explicitly move focus ( using Alt-j etc ) to the editing window. In Buffer Mode, selecting a buffer in the Speedbar loads it in the editing window, but focus and keypress events correctly stay in the Speedbar window. Thanks, deech

3 2

Merged functionality from X.L.ThreeColumnsMiddle into X.L.ThreeColumns (and some new features)
by Anders Engström 05 May '09

05 May '09

I had a look at X.L.ThreeColumnsMiddle and X.L.Threecolumns and noticed that they are very similar, actually the first one is based on the second one. Therefore I tried to merge them together and here is the result. This somewhat breaks the configuration syntax, but that is unavoidable. There was a difference in the way column sizes was specified, I adopted the one from the Middle-version since I can't understand why it was done as it was in the original code. I also extended the ability to specify the column size a bit by allowing negative fractions. Negative fractions will specify the size for the slave columns and the behaviour will be different when there are only two windows to manage. Enjoy. /Anders Engström

3 3

StackSet patch
by Wouter Swierstra 05 May '09

05 May '09

I found a really minor bug in the "new" function in StackSet.hs. I've attached a patch to fix it. More interesting, however, is how I found this. I've been transcribing XMonad's StackSets to the functional language/proof assistant Coq. I've set up a darcs repository with my work so far: darcs get www.cs.nott.ac.uk/~wss/repos/StackSet At the moment I have a fairly complete implementation of StackSets in Coq. I have to admit that I did cut a few corners here and there, but there's nothing that can't be fixed with a bit more work. From this Coq file, you can (in principle) extract Haskell code that is pretty close to the current StackSet.hs. I should emphasize that I haven't proven much about StackSets just yet. This only shows that the definitions in StackSet.hs can be made total (i.e. non-crashing and terminating) in a richer type theory. It should be fun to prove some QuickCheck properties in Coq – which is what I'd like to do next. Wouter

2 1

darcs patch: Add lib to ghc searchpath with recompila... (and 1 more)
by Adam Vogt 04 May '09

04 May '09

Sat Mar 21 19:29:07 EDT 2009 Adam Vogt <vogt.adam(a)gmail.com> * Add lib to ghc searchpath with recompilation check Sun May 3 19:54:15 EDT 2009 Adam Vogt <vogt.adam(a)gmail.com> * Only watch mtime for .hs, .lhs, .hsc for ~/.xmonad/lib Previously xmonad would force a recompile due to the object files being too new, so only look at files which may contain haskell code.

1 0

Re: [xmonad] darcs patch: Config.hs, Operations.hs: +unfloat, unfloatFocused fun...
by Gwern Branwen 04 May '09

04 May '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Sat, May 2, 2009 at 3:54 PM, Don Stewart wrote: > They're in the default Config -- i.e. that binding is already in scope. > > So people are intentionally duplicating parts of the default config for > some reason. > > I think this is quite different to the case where there is a spontaneous > idiom appearing. > > -- Don You refer to just the ones duplicating the mod-t binding? I'd say it's an interesting example of how our keybinding system is suboptimal - even moderately competent users should not find themselves duplicating stuff like this. But anyway, even if you filter out the ones binding to xK_t, there're still 10 configs using this same function definition. Is that not enough? Before I invest anymore time in trying to make configs more concise & usable by factoring out commonalities, I'd appreciate some hard guidelines on when something is meritorious enough to be put in core and when it is not. - -- gwern -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Use GnuPG with Firefox : http://getfiregpg.org (Version: 0.7.5) iEYEAREKAAYFAkn9DpsACgkQvpDo5Pfl1oKF6gCeItWqEw6tOJZesV3ONrYWJmbB OcgAnjG98E+ZW1cwFmFUfjbfdjkNQRA3 =VybT -----END PGP SIGNATURE-----

2 1

darcs patch: U.Loggers: add maildirNew, other loggers, and logger f...
by Wirt Wolff 04 May '09

04 May '09

Sat Apr 11 22:13:56 MDT 2009 wirtwolff(a)gmail.com * U.Loggers: add maildirNew, other loggers, and logger formatting utilities Rework of the Logger portions of patches originally from seanmce33(a)gmail.com to apply without conflicts, plus several formatting utilities for use with X (Maybe String) aka Loggers.

3 2

patch: New XMonad.Layout.MessageControl module.
by Quentin Moser 04 May '09

04 May '09

Hi, These patches provide a message escape/filtering facility intended to make it easier to control complex nested layouts via messages. The first one provides "unEscape" and "ignore" modifiers you could use to write something like this: > import XMonad.Layout.MessageControl > > myLayout = Full ||| gimp ||| ... > where gimp = ignore NextLayout $ ignore JumpToLayout $ unEscape $ > mastered 0.01 0.2 (simpleTabbed ||| Grid) > > nextOuterLayout = sendMessage NextLayout > nextInnerLayout = sendMessage $ escape NextLayout (see the XMonad.Layout.MessageControl patch for details. For clarification, "ignore" blocks all messages of the _same type_ as its parameter.) However, neither XMonad.Layout.(|||) nor XMonad.Layout.LayoutCombinators.(|||) can be used with this, because they both send messages (NextLayoutNoWrap) which have a private type and therefore cannot be filtered. Thus the patch to X.L.LayoutCombinators, which moves the NoWrap messages from their own type into the JumpLayout type, so that they can now be intercepted with "ignore JumpToLayout". I also made these constructors public because I don't like exporting data types with only part of their constructors, but that's not actually necessary and can be reverted if wanted. ... Also, when adding these modifiers into my Big Monstrous LayoutHook of Hell I had to add an {-# OPTIONS_GHC -fcontext-stack=40 #-} pragma to my xmonad.hs to prevent a context reduction overflow =).

3 2

darcs patch: ThreeCol - Update docs to match reality
by Anders Engstrom 04 May '09

04 May '09

Sun May 3 21:07:55 CEST 2009 Anders Engstrom <ankaan(a)gmail.com> * ThreeCol - Update docs to match reality

2 1

darcs patch: nameTail - Remove the first word of a layout description
by Anders Engstrom 04 May '09

04 May '09

Sun May 3 12:59:50 CEST 2009 Anders Engstrom <ankaan(a)gmail.com> * nameTail - Remove the first word of a layout description

2 1

Turning emacs mini-buffer window into a strut
by John Yates 03 May '09

03 May '09

This is my first appearance in the xmonad community. Those tracking awesome may recognize this post as similar to one I posted earlier on that mailing list. Some backstory As a longtime C++ programmer I had assumed that awesome's imperative codebase (C++ and Lua) would present a gentler learning curve. I made some initial progress but ultimately found awesome still too immature and undocumented to give me confidence of achieving my various goals (of which possibly more in a subsequent posting). On switching to xmonad the greater maturity, generally good documentation, abundance of contributed modules and availablity of example configurations helped me greatly. The only thing I miss from awesome is its somewhat snappier performance. My guess would be that that has nothing to do with choice of implementation or scripting language, but rather with the fact that awesome is built on xcb while xmonad is built on classic xlib. My current challenge Years ago I loved Apollo workstations' DM (Display Manager). Ever since becoming an emacs user I have dreamed of recreating that environment. The emergence of robust tiling window managers and the example of Drew Adams' OneOnOne package (http://www.emacswiki.org/emacs/OneOnOneEmacs) leads me to believe that after a couple decades the dream may now be close to realization. For reference my environment is Ubuntu Jaunty, Gnome with a single top panel on a 1920x1200 screen. Under Gnome/Metacity I have emacs-snapshot (23.0.93.1) more or less working in the the single mini-buffer for all windows mode. (Here I use the term window to refer to what in the Emacs world would be called a frame.) The mini-buffer window is positioned at the bottom of the screen and is full-screen wide. Alternatively I can position the mini-buffer at the top of the screen just below the Gnome panel. Now I want to move this Emacs arrangement to xmonad. Because I have arranged for the mini-buffer window to have a distinct resource type I can recognize it in a manage hook. From the xmonad FAQ and some googling I believe that when that window appears I need to set its override-redirect attribute to true and define it as a strut. Though I am working my way through Hal Daumé's "Yet Another Haskell Tutorial" I fear it may be a while before I can code such a doStrut function. Thus my appeal to the readers of this list. My sense is that when the mini-buffer window appears it is properly sized and positioned. Thus there should be no need to compute the strut components, they should be directly liftable from the window. Thanks in advance for any help, /john

4 4