Daniel Gröber (dxld)

Oh that's no problem at all we can derive that from cabal's setup-config. The problem is more architectural since a ghc-mod built using ghc but linked against ghcjs would only...

Oh yeah sure, I'm not suggesting we link against ghc and ghcjs at the same time. I'm merely pointing out that we don't have any dispatch logic anywhere to handle...

I suppose but that's just not a very nice user experience. Anyways in the meantime I see no reason we can't at least add support for this so feel free...

Well how about you create a new issue titled "Poll: Add ghcjs support to ghc-mod" and post a link to that to reddit and maybe haskell-cafe and just let people...

I dunno you'd have to ask @luite, I see no reason not to use that patch as a basis though if it works. Actually looking at it now I think...

During MuniHac me and @meditans figured out that in addition to what I said above we need to have cabal-helper handle using either `Distribution.Simple.GHC` or `Distribution.Simple.GHCJS` to get the rendered...

FYI the coinstall stuff has moved moved forward since my last post here, see https://github.com/DanielG/ghc-mod/issues/615#issuecomment-309964717. It's time for someone interested in this feature to start thinking about how to detect...

I suppose now that we use the STACK_EXE environment variable as a strong hint that we should prefer stack over cabal we could do that. If you want to implement...

Actually looking at the code it wouldn't be as easy as I thought. This would need some refactoring of internals.

We should probably detect all the relevant combinations of language flags and turn on object code generation for those that need it, like we do with NoLink/LinkInMemory and TH already....