call to stack / get-cabal-configuration delays editing file

[bergey]

On a typical day at work I load 10-30 cabal projects, and the first file I open in each takes ~ 4 seconds to load. I have flycheck-haskell-setup in my haskell-mode-hook, so I cannot view or edit the file until the call tostack runghc get-cabal-configuration.hs` completes. I think it would be better if this slow call were non-blocking, so I can edit the file immediately, and flycheck errors will catch up.

Another approach would be to make get-cabal-configuration faster, by pre-compiling, changing its code, or both. In one test, I found that compiling took ~2s, and running took ~2s (6s / 1.3s with -O2, which is probably a better idea). I suspect a 1s pause will still annoy me, so I think the async change will have better ROI.

I'm testing a patch locally that makes this call async. If you like the idea, I can clean it up and open a PR once I've used it for a few days. In which case, a few questions about how you want the code:

• is async an acceptable dependency?
• Is it reasonable to assume that get-cabal-configuration only prints to STDERR if it exits with a non-success error code, so I can let emacs mix STDOUT and STDERR and just check the exit code?

The patch I'm running now assumes yes to both, which makes the change smaller.

[sergv]

@bergey Thanks for bringing this up. Unfortunately I'm not actively maintaining nor actually using flycheck-haskell any more, however I can merge some small fixes. Your patch sounds great and is probably what should ultimately be done.

However, for me issue with merging your proposed patch that makes the calls asynchronous is that once something breaks, someone will have to debug and fix it. Would you be interested in maintaining this part of flycheck-haskell going forward once it's merged?

Regarding your questions about async dependency and output from get-cabal-configuration:

• I think async is ok since choosing something different will likely result in some kind of dependency. Although perhaps emacs threads need to be considered
• I think it's resonable to where get-cabal-configuration will print its output. The assumption is reasonable and the file is under our control anyway

[bergey]

Yes, I'd be happy to maintain this part of flycheck-haskell going forward. I've been using my patch for several weeks now; I'll try to turn it into a PR sometime in the next week.