<div dir="ltr">Whaou thanks for the long and complete answer, I'll see what's possible to do.<div><br></div><div>Cheers</div></div><br><div class="gmail_quote"><div dir="ltr">Le Fri, Sep 1, 2017 à 7:11 PM, Brandon Allbery <<a href="mailto:allbery.b@gmail.com">allbery.b@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Sep 1, 2017 at 9:38 AM, Thomas Droxler <span dir="ltr"><<a href="mailto:thomas.droxler@gmail.com" target="_blank">thomas.droxler@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>I'm a big fan of <a href="https://github.com/junegunn/fzf" target="_blank">FZF</a> and I wanted to make an xmonad integration, to work like <a href="https://hackage.haskell.org/package/xmonad-contrib-0.13/docs/XMonad-Util-Dmenu.html" target="_blank">Util.Dmenu</a>. I'm quite new to Haskell and I got some problems to do it.</div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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).</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.)</div><div><br></div><div>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.</div><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra">-- <br><div class="m_7748582243453110885gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>brandon s allbery kf8nh                               sine nomine associates</div><div><a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a>                                  <a href="mailto:ballbery@sinenomine.net" target="_blank">ballbery@sinenomine.net</a></div><div>unix, openafs, kerberos, infrastructure, xmonad        <a href="http://sinenomine.net" target="_blank">http://sinenomine.net</a></div></div></div>
</div></div></blockquote></div>