- xmonad - Haskell.org

Regexp WM_NAME ?
by Pablo Olmos de Aguilera C. 14 May '12

14 May '12

In pentadactyl (a firefox addon) you can write in an external editor instead a textbox, by default it spawns a gvim window and everytime it opens a pentadactyl.txt in tmp folder. Imho that behaviour is way more easier writing on a floating window. Using xprop I found the WM_NAME it's the only variable that doesn't change, so I thought that using it in my myManageHook would do it. $ xprop | grep 'WM_NAME' WM_NAME(STRING) = "pentadactyl.txt (/tmp) - GVIM" myManageHook = (composeAll , concat $ [ , [ className =? "stalonetray" --> doIgnore] -- a lot of output removed -- , [ title =? "pentadactyl.txt (/tmp) - GVIM" --> doFloat] ] I restarted xmonad, reopened the editor and I found that it doesn't work, I tried to check wm_name again, and guess what? WM_NAME(STRING) = "pentadactyl.txt (/tmp) - GVIM1" Obviously the last part "GVIM" changes all the time, so I can't know in advance which is gonna pick. There's some way to regexp the wm_name part? Until now, I couldn't find anything about this topic :( Regards, -- Pablo Olmos de Aguilera Corradini - @PaBLoX http://www.glatelier.org/ http://about.me/pablox/ http://www.linkedin.com/in/pablooda/ Linux User: #456971 - http://counter.li.org/

3 6

Strange workspace switching bug in my config
by Leo Alekseyev 13 May '12

13 May '12

Hi all, A couple of years back I made the following addition to my xmonad.hs: instead of 10 workspaces, it admits 20 workspaces, logically arranged in two rows of 10. I think of it as having a "scratch" workspace for every main workspace, and I use up/down arrows to switch between the main and the scratch workspace. For instance, if you are on workspace 4, Mod4-<down> will move to workspace 4SCR and Mod4-<up> will move back to workspace 4. Recently this config started misbehaving (without any changes to xmonad.hs, but with possible changes in xmonad/GHC version to 0.10 and 7.4.1 as my system was upgraded). In particular, in the example above, now Mod4-<down> moves from workspace 4 to workspace 3SCR and Mod4-<up> then moves from 3SCR to 2. To fix it, I have to log in and out of X, but the problem always reoccurs, possibly after sleep/resume cycle(?). The embarrassing thing here is that I haven't touched Haskell in a while, and barely grok my config anymore, so I don't know where to start troubleshooting. The code I described seems straightforward enough, so it's my hope that maybe someone here can tell me what is going on without too much effort... The relevant parts of my config are below, and the full file in its horrifying glory is at http://hpaste.org/68453. If someone seems something obviously amiss, please shout... --leo myWorkspaces = ["1:terminals", "2:emacs", "3:web", "4", "5", "6", "7","8","9","0"] ++ map (\x -> show x ++ "SCR") ([1..9]++[0]) ..... zeroSub 0 = 10 zeroSub x = x jumpToMain = gets windowset >>= \W.StackSet { W.current = W.Screen { W.workspace = w } } -> withNthWorkspace W.greedyView (-1+(zeroSub $ read [head(W.tag w)])) jumpToScratch = gets windowset >>= \W.StackSet { W.current = W.Screen { W.workspace = w } } -> withNthWorkspace W.greedyView (9+(zeroSub $ read [head(W.tag w)])) .... , ("M-<Up>", jumpToMain) , ("M-<Down>", jumpToScratch)

1 0

* UrgencyHooks made available as Window -> X () functions [patch]
by David McLean 10 May '12

10 May '12

My previous attempt at this patch was flawed, as gwern pointed out, in that it completely broke backward compatibility with all existing configurations using the module. This variation addresses that issue, preserving backward compatibility completely. 1 patch for repository http://code.haskell.org/XMonadContrib: Fri May 4 16:23:39 EST 2012 gopsychonauts(a)gmail.com * UrgencyHooks made available as Window -> X () functions Adds an UrgencyHook instance for the type Window -> X (), allowing any such functions to be used directly as UrgencyHooks. The Show and Read constraints were removed from the UrgencyHook class in order to permit this; these constraints were required only in a historical implementation of the module, which used a layout modifier. All existing configurations using UrgencyHooks should remain fully functional. New configs may make use of this modification by declaring their UrgencyHook as a simple Window -> X () function.

3 2

silly behavior of killWord in XMonad.Prompt
by Brent Yorgey 10 May '12

10 May '12

I realized today that the behavior of killWord from XMonad.Prompt is surprising to me. In particular, when you iterate killWord, it deletes first a word, then a space, then the next word, then the next space, and so on. I (an emacs user) expect killWord to delete a word AND any whitespace that happens to come before it. (Hmm... I tested with vim and it seems that 'dw' deletes a word along with any TRAILING whitespace. So emacs and vim differ here... but the point is that killWord emulates neither.) I looked into it and it turns out that the behavior of killWord is even sillier than I thought. It deletes an entire word of non-whitespace characters *or a single space*. (So if there are multiple spaces you have to call killWord once for each space before you finally get to delete the word that comes after.) And if the next character is a tab it doesn't delete anything at all! For concreteness, here's the change I made: diff -rN old-XMonadContrib/XMonad/Prompt.hs new-XMonadContrib/XMonad/Prompt.hs 525,528c525 < delNextWord w = < case w of < ' ':x -> x < word -> snd . break isSpace $ word --- > delNextWord = snd . break isSpace . dropWhile isSpace Thoughts? If anyone really likes the old behavior then I can make two versions. Or if there is consensus that the old behavior is silly and the new behavior is better, then I'll just push the above change. I could also be talked into swapping the order of the break and dropWhile in order to emulate vim; I don't really care as long as it's one of the two. -Brent

8 10

bringing xmonad into the threaded world
by wagnerdm＠seas.upenn.edu 08 May '12

08 May '12

There have been various times when I've wished I could just spawn a thread in xmonad. Just recently, for example, it was pointed out to me that the default mod+q binding starts a brand new process just to keep xmonad responsive while it recompiles the configuration file. This is silly. Here is a patch bundle that makes xmonad ask X to be thread-safe, and rewrites the default mod+q binding to take advantage of the new thread safety. ~d

4 11

vmware and Alt_ binding
by Richard WAtson 08 May '12

08 May '12

Here's a newbie question I use Outlook in a vmware Windows7 VM. Usually, but not always, when the VM has focus, an Alt+2 (say) keystroke is directed to the Outlook app rather than switching to workspace 2. I'd like to guarantee the workspace switch behaviour. Is there a solution to this? Regards Richard

2 1

Patch: X.H.FadeInactive and X.A.GridSelect
by Jesper Reenberg 07 May '12

07 May '12

X.H.FadeInactive: Attached is my previous patch, which seems to have been stranded. Anyways there don't seem to have been any objections. X.A.GridSelect: * Fixed X.A.GridSelect to be consistent in the way it (now) sorts the shown elements when modifying the searchString. The implemented ordering sorts based on how "deep the needle is in the haystack", meaning that searching for "st" in the elements "Install" and "Study" will order them as "Study" and "Install". Previously there was no ordering and when using GridSelect to select workspaces, the ordering was not consistent, as the list of workspaces (if not modified manually) is ordered by last used. In this case either "Study" or "Install" would come first depending on which workspace was last visited. By not having it consistent, it really fucks with muscle memory. I'm open for other ways of sorting the elements when the searchString is not null, however sorting them in the order of "the depth of the match" seems to be very intuitive, as I (and others I have talked to) tend to write the first letters of the word that is searched for. -- Reenberg

3 2

FloatKeys and window decorations
by Sergey Khorev 07 May '12

07 May '12

Hi, It looks like contrib's FloatKeys do not play nicely with decorated windows. For instance, if I activate simpleFloat and try to use keysMoveWindow, the decoration simply disappears. Moreover, if I remove the call to `float' from keysMoveWindow, I end up with two separate pieces: the window moved and its decoration. Any idea how it can be fixed? Or are those fundamentally incompatible?

2 1

Changes to XPrompt
by Carlos López Camey 06 May '12

06 May '12

Hello xmonaders, I started to code something upon XPrompt, but I noticed that what I would like the code to do, needs some changes in XPrompt, which I'm not sure should go into XPrompt, or into a new type of Prompt (not related to XPrompt). This question sometimes makes me doubt when changing XPrompt.hs, so I thought I would ask and decide where to do it. The changes would be: * Autocomplete based on several modes (there is always a mode set) The autocomplete items are generally path to files, mode 1 could use for example `locate %s`, mode 2 `recollq` [0] (searches for tokens inside files) and mode 3 `locate --regexp %s` to autocomplete. * one-column-only list of autocompletions For the purpose, they are always paths, so they are quite large to keep it in different columns. But this be a setting on the configuration. * Navigating through completion items and changing autocompletion list on "real time" There is always an item highlighted (if items > 0) The highlighted item not necesarilly is equal to the prompt buffer text. I may write "xmonad.hs" but the autocomplete item shows a full path highlighted. This implies adding an additional field to XPState, complIndex :: Int, that knows which item to highlight next (not based on the buffer's text) * Action is not necesarilly a String -> X a. I'd like to count on a Map Extension (String -> String) in some config, where type Extension = String. This map would describe what to do with each file depending on its extension. e.g. an element of the map could be (".org",\path -> "emacs "++path). So I'm not sure how the new signature would be: String -> X a? but this String would be the command sent to spawn, computed using a function that uses the map described above. I know this is a long list of features, but I hope it to be materialized eventually. My questions would be then, is it right to do a new XPrompt? it's hard not to think on changes braking current xmonad.hs configurations. In case a new Prompt is needed, name it LauncherPrompt, does it belong to xmonad-contrib? Creating a new Prompt would imply having different config types (XPConfig and LauncherPromptConfig), and very similar actions on both each prompt module.. for example killBefore :: XP() and killBefore :: LauncherP (). That's not acceptable IMHO. I appreciate your comments, [0] http://www.lesbonscomptes.com/recoll/

2 1

* Converted UrgencyHooks to simple Window -> X () functions [patch]
by David McLean 03 May '12

03 May '12

1 patch for repository http://code.haskell.org/XMonadContrib: Fri May 4 10:38:29 EST 2012 gopsychonauts(a)gmail.com * Converted UrgencyHooks to simple Window -> X () functions Previously, UrgencyHooks were members of the typeclass UrgencyHook, and had to implement Read and Show instances. This was for historical reasons, as originally the UrgencyHook was stored as a layout modifier. Changes in the module's implementation---it now uses handleEventHook and logHook instead---mean that those constraints are no longer needed. Thus, changing the UrgencyHook to a simpler single type is possible. This makes writing new UrgencyHooks simpler, as now they're just functions and don't require a whole new typeclass instance. It also allows for useful behaviour such as UrgencyHook being a Monoid: this increases cohesion in an XConfig definition since multiple UrgencyHooks may now be combined with <+>, just as manageHook and logHook may be. Regrettably, this does break compatibility with any previously-defined custom urgency hooks, since the UrgencyHook typeclass no longer exists.

3 4