Daniel Gröber (dxld)
Daniel Gröber (dxld)
@enolan that does sound like a reasonable thing to do. I think this would have to go somewhere in `runGmlTWith`. But the code dealing with Stack is somewhere deep in...
After meditating on this problem for a while at MuniHac I've decided the most immediately useful way to fix this is to make the `ghc-mod` executable a wrapper for `real`...
FIY I've implemented a new field ([`scope: private`](https://cabal.readthedocs.io/en/latest/developing-packages.html#pkg-field-executable-scope)) in Cabal HEAD (to be released as 2.x) that toggles installing into `$libexec/$libexecsubdir` which gives us a path like `/usr/local/libexec/x86_64-linux-ghc-8.0.2/mypkg-0.1.0/` most importantly...
Nope. FYI this only applies to ghc-mod, HaRe (and HIE for that matter) have to implement this seperately.
I think this might happen when I have at least two buffers open, both declaring `module Main` and both are being mapped down to the library component because they are...
@kazu-yamamoto could you please implement unmapping files in the elisp frontend? I think the problem here is that we only ever map-file but never remove the mapping. I think we...
@PierreR Give this branch a spin: #693 I've been carrying that patch locally for a while now, cleaned it up a bit.
@PierreR Can you open a new issue and describe exactly what you're doing to cause the error? A copy of `*GHC Debug*` would be enormously helpful too.
First attempt at fixing this: 02f664aae386775cd1fecce2c0763e28b84cfd81. Will keep this in the dev-elisp branch until I'm convinced it doesn't race or break anything. Testers welcome.