From thomas.droxler at gmail.com Fri Sep 1 13:38:46 2017 From: thomas.droxler at gmail.com (Thomas Droxler) Date: Fri, 01 Sep 2017 13:38:46 +0000 Subject: [xmonad] FZF integration Message-ID: Hi all, I'm a big fan of FZF and I wanted to make an xmonad integration, to work like Util.Dmenu . I'm quite new to Haskell and I got some problems to do it. The main problem I have is that fzf needs to run in a shell and when I run an external terminal, it sucessfully pops up, but then the rest of the code continue to be executed and I can't wait for the output of fzf. Moreover, fzf give an output in the terminal, but then how do I get the output in my haskell code? I tried several think and the closest I got is to write the result of fzf in a file and read it back, but I cannot wait until my terminal shutdown to read my file, I have something like: *(filePath, handle) <- openTempFile "*path*" "fzf"* *hClose handle* *(_, _, _, procHandle) <- runInteractiveCommand ("xterm -e '*dataForFZF* | fzf >" ++ filePath ++"'")* *-- Here I need to wait that my term close, I tried: waitForProcess procHandle* *-- But it just freeze my Xmonad, and not sure a while loop on getProcessExitCode is better* *str <- readFile filePath* doSomethingWith* str* *removeFile filePath* Anyone has a hint to do this? Thanks a lot, cheers. Thomas Droxler -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Fri Sep 1 17:11:24 2017 From: allbery.b at gmail.com (Brandon Allbery) Date: Fri, 1 Sep 2017 13:11:24 -0400 Subject: [xmonad] FZF integration In-Reply-To: References: Message-ID: On Fri, Sep 1, 2017 at 9:38 AM, Thomas Droxler wrote: > I'm a big fan of FZF and I wanted to > make an xmonad integration, to work like Util.Dmenu > . > I'm quite new to Haskell and I got some problems to do it. > This isn't so much about Haskell as it is about asynchronous programming with the POSIX process model. Specifically: we disable POSIX's normal wait behavior, so waitForProcess will not work (it will wait for all outstanding processes matching the process specification and then fail, because processes are being auto-reaped. See the POSIX documentation for SIGCHLD). The ideal way to do this asynchronously is to run it in a separate process and have it pass the result back to xmonad as an X11 client message you can intercept in handleEventHook. But the current Haskell binding for clientMessage events is less than ideal; it can still be done, but it is more annoying than it should be. If (and ONLY if) the subprocess is guaranteed to return quickly AND not map a managed window, there is XMonad.Util.Run.runProcessWithInput or runProcessWithInputAndWait. If it maps a window that needs to be managed, this WILL hang. If some other process tries to map a window that needs to be managed while this is waiting, it will fail to do so because if xmonad is waiting on a subprocess, it is not managing windows. We can't do this in subthreads because (a) X11 can't do proper multithread (b) POSIX signals and subprocesses are per process, not per thread, so you cannot launch and collect a subprocess in a separate thread without changing the behavior of other threads. (And you cannot have multiple Haskell threads manipulating the same xmonad state, because it is not global. This is why you'd have to send a clientMessage to the main thread with any response.) Do remember that you are doing this in the program that manages new windows; if you are making it wait for something else, it is not able to manage new windows. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.droxler at gmail.com Fri Sep 1 17:30:49 2017 From: thomas.droxler at gmail.com (Thomas Droxler) Date: Fri, 01 Sep 2017 17:30:49 +0000 Subject: [xmonad] FZF integration In-Reply-To: References: Message-ID: Whaou thanks for the long and complete answer, I'll see what's possible to do. Cheers Le Fri, Sep 1, 2017 à 7:11 PM, Brandon Allbery a écrit : > On Fri, Sep 1, 2017 at 9:38 AM, Thomas Droxler > wrote: > >> I'm a big fan of FZF and I wanted to >> make an xmonad integration, to work like Util.Dmenu >> . >> I'm quite new to Haskell and I got some problems to do it. >> > > This isn't so much about Haskell as it is about asynchronous programming > with the POSIX process model. Specifically: we disable POSIX's normal wait > behavior, so waitForProcess will not work (it will wait for all outstanding > processes matching the process specification and then fail, because > processes are being auto-reaped. See the POSIX documentation for SIGCHLD). > > The ideal way to do this asynchronously is to run it in a separate process > and have it pass the result back to xmonad as an X11 client message you can > intercept in handleEventHook. But the current Haskell binding for > clientMessage events is less than ideal; it can still be done, but it is > more annoying than it should be. > > If (and ONLY if) the subprocess is guaranteed to return quickly AND not > map a managed window, there is XMonad.Util.Run.runProcessWithInput or > runProcessWithInputAndWait. If it maps a window that needs to be managed, > this WILL hang. If some other process tries to map a window that needs to > be managed while this is waiting, it will fail to do so because if xmonad > is waiting on a subprocess, it is not managing windows. > > We can't do this in subthreads because (a) X11 can't do proper multithread > (b) POSIX signals and subprocesses are per process, not per thread, so you > cannot launch and collect a subprocess in a separate thread without > changing the behavior of other threads. (And you cannot have multiple > Haskell threads manipulating the same xmonad state, because it is not > global. This is why you'd have to send a clientMessage to the main thread > with any response.) > > Do remember that you are doing this in the program that manages new > windows; if you are making it wait for something else, it is not able to > manage new windows. > > -- > brandon s allbery kf8nh sine nomine > associates > allbery.b at gmail.com > ballbery at sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kilian at evang.name Fri Sep 1 20:57:08 2017 From: kilian at evang.name (Kilian Evang) Date: Fri, 1 Sep 2017 22:57:08 +0200 Subject: [xmonad] XMonad.Actions.UpdateFocus doesn't work Message-ID: Hi, documentation for XMonad.Actions.UpdateFocus says it "Updates the focus on mouse move in unfocused windows." However, for me (using Ubuntu 16.04, xmonad installed from Ubuntu repository), it doesn't seem to have any effect. Here is my minimal xmonad.hs: import XMonad import XMonad.Actions.UpdateFocus main = xmonad $ defaultConfig { focusFollowsMouse = True, startupHook = adjustEventInput, handleEventHook = focusOnMouseMove } Any idea what's wrong? Cheers, Kilian From allbery.b at gmail.com Fri Sep 1 23:07:43 2017 From: allbery.b at gmail.com (Brandon Allbery) Date: Fri, 1 Sep 2017 19:07:43 -0400 Subject: [xmonad] XMonad.Actions.UpdateFocus doesn't work In-Reply-To: References: Message-ID: On Fri, Sep 1, 2017 at 4:57 PM, Kilian Evang wrote: > Any idea what's wrong? > I'd have to review xmonad's setup code to be certain, but I think the startupHook no longer works. Instead, the mask changes it makes need to be exported and applied to the rootMask and clientMask fields of the XConfig. File a bug on the xmonad-contrib issue tracker, please, referencing this message from the list archives. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: