[xmonad] FZF integration

[Thomas Droxler]

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 <allbery.b at gmail.com> a
écrit :

> On Fri, Sep 1, 2017 at 9:38 AM, Thomas Droxler <thomas.droxler at gmail.com>
> wrote:
>
>> I'm a big fan of FZF <https://github.com/junegunn/fzf> and I wanted to
>> make an xmonad integration, to work like Util.Dmenu
>> <https://hackage.haskell.org/package/xmonad-contrib-0.13/docs/XMonad-Util-Dmenu.html>.
>> 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: <http://mail.haskell.org/pipermail/xmonad/attachments/20170901/86c459a1/attachment.html>