April 2012 - xmonad - Haskell.org

Issue 429 in xmonad: X.A.DynamicWorkspaces command to delete specified tag
by codesite-noreply＠google.com 03 Jan '13

03 Jan '13

Status: New Owner: ---- New issue 429 by jjfoe...(a)earthlink.net: X.A.DynamicWorkspaces command to delete specified tag http://code.google.com/p/xmonad/issues/detail?id=429 X.A.DynamicWorkspaces contains 'removeWorkspace' which deletes the current workspace. It would be useful to me to have a similar command with which I could delete any workspace by name. I would use this to write a 'workspaces cleanup' procedure that auto-deletes empty auxiliary workspaces.

1 3

Re: Issue 316 in xmonad: AvoidStruts gives wrong window heights with vertically stacked screens
by codesite-noreply＠google.com 03 Jan '13

03 Jan '13

Comment #3 on issue 316 by liskni.si: AvoidStruts gives wrong window heights with vertically stacked screens http://code.google.com/p/xmonad/issues/detail?id=316 http://www.haskell.org/pipermail/xmonad/2009-November/009145.html This, I believe, fixed the issue and discusses why it changes the strut semantics incompatibly with wm-spec. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings

1 2

Re: Issue 242 in xmonad: inter screen handling doesn't work with xrandr --right-of, works with --left-of
by codesite-noreply＠google.com 02 Jan '13

02 Jan '13

Comment #1 on issue 242 by nwfilardo: inter screen handling doesn't work with xrandr --right-of, works with --left-of http://code.google.com/p/xmonad/issues/detail?id=242 At least on my ThinkPad X200, the problem is that the LVDS output is not by default the primary display. It appears that the particular xinerama calls xmonad makes do not enumerate displays in left-to-right order but in some other order (as might be obvious, I'm not an expert at X11). Try running "xrandr --output LVDS --primary"; then -w should be the LVDS panel and -e should be the VGA output.

1 5

Re: Issue 240 in xmonad: recompilation fails silently
by codesite-noreply＠google.com 01 Jan '13

01 Jan '13

Updates: Status: Patch Owner: SpencerJanssen Comment #3 on issue 240 by vogt.adam: recompilation fails silently http://code.google.com/p/xmonad/issues/detail?id=240 Attached is a patch to accomplish the same indirectly by checking that the target executable is actually updated. But given that we have enough trouble to include the code for popping up an xmessage to welcome new users, then this patch might not be worth including since it addresses a rarer issue with somewhat more code. Attachments: check-that-the-expected-xmonad__arch__os-is-actually-updated_.dpatch 12.1 KB -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings

1 2

Re: [xmonad] Issue 225 in xmonad: Allow single click to focus and pass click to window
by codesite-noreply＠google.com 01 Jan '13

01 Jan '13

Updates: Summary: Allow single click to focus and pass click to window Comment #8 on issue 225 by wirtwo...(a)gmail.com: Allow single click to focus and pass click to window http://code.google.com/p/xmonad/issues/detail?id=225 cirwin on #xmonad reports that manually merging the code in the referenced patch with current darcs enables one click to focus and pass the event to the window. An updated patch that applies cleanly to current darcs X.Main and X.Operations would be welcome. Updating title to remove "synthetic events" since they are not relevant here.

1 7

Re: Issue 211 in xmonad: Error output inconsistency
by codesite-noreply＠google.com 01 Jan '13

01 Jan '13

Comment #1 on issue 211 by byorgey: Error output inconsistency http://code.google.com/p/xmonad/issues/detail?id=211 Status? This seems like a pretty simple change, do other developers have an opinion on this? -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings

1 1

Issue 360 in xmonad: shellPromptHere from XMonad.Actions.SpawnOn freezes upon files with Chinese names
by codesite-noreply＠google.com 15 Dec '12

15 Dec '12

Status: New Owner: ---- New issue 360 by wei.hoo: shellPromptHere from XMonad.Actions.SpawnOn freezes upon files with Chinese names http://code.google.com/p/xmonad/issues/detail?id=360 What steps will reproduce the problem? 1. Bind a key combination to shellPromptHere 2. mkdir /tmp/new; cd /tmp/new 3. touch 1; touch 测试 4. Invoke shellPromptHere, type in "emacs /tmp/new/", press TAB What is the expected output? What do you see instead? Observe that the shell prompt window freezes. No keybindings are accepted, such as C-a, C-e, C-g. However, XMonad keybindings are still effective. At this point we have to press M-q to restart XMonad. What version of the product are you using? On what operating system? xmonad-darcs and xmona-contrib-darcs on Arch Linux. GHC-6.12. Are you using an xmonad.hs? Please attach it and the output of "xmonad --recompile". Please provide any additional information below. If we remove /tmp/new/1 and only keep /tmp/new/测试, typing "emacs /tmp/new/ [TAB]" doesn't freeze the shell prompt. The Chinese-named file isn't shown in the completion, but we can still press C-g to cancel the shell prompt. The font I'm using does support Chinese. PS: I kind of remember this wasn't a problem with ghc-6.10, but I'm not sure. Attachments: xmonad.hs 6.8 KB -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings

1 1

Re: Issue 177 in xmonad: xmonad does not follow ICCCM and ignores WM_TAKE_FOCUS protocol
by codesite-noreply＠google.com 05 Dec '12

05 Dec '12

Comment #24 on issue 177 by vogt.adam: xmonad does not follow ICCCM and ignores WM_TAKE_FOCUS protocol http://code.google.com/p/xmonad/issues/detail?id=177 Geoff Reedy's last patch doesn't apply cleanly against latest darcs (due to the merging of extensible state stuff). Attached is a patch bundle including the old ones that probably works as the old one did. Attachments: track-currently-processing-event.dpatch 16.1 KB -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings

4 108

darcs patch: Config.hs: rm commented out keybinding (... (and 1 more)
by gwern0＠gmail.com 15 Nov '12

15 Nov '12

2 patches for repository community.haskell.org:/srv/code/xmonad: Thu Jan 12 19:01:15 EST 2012 gwern0(a)gmail.com * Config.hs: rm commented out keybinding (dead for years) Thu Jan 12 20:04:10 EST 2012 gwern0(a)gmail.com * Config.hs: implement mod-shift-/ newbie keybinding guide per http://code.google.com/p/xmonad/issues/detail?id=182

6 7

Re: Issue 4 in xmonad: Separate focus for tiled and floating layers
by codesite-noreply＠google.com 01 Oct '12

01 Oct '12

Comment #34 on issue 4 by vogt.adam: Separate focus for tiled and floating layers http://code.google.com/p/xmonad/issues/detail?id=4 I see how TrackFloating is still unsatisfactory. Perhaps xmonad (and the modified layout) focus should be modified only when focus goes to tiled due to a window disappearing, and for crossing events: (CrossingEvent {ev_window=w, ev_event_type=t, ev_mode=m}) | t == enterNotify, m == notifyNormal = Modifying xmonad focus from a layout is tricky, since it's difficult to know that infinite loops of refreshing can not occur. Splitting it up as layout and eventHook may be simpler.

1 3