Closed 3noch closed 8 years ago
I'm not sure how one would differentiate between regular Haskell and ghcjs... I'll see what I can do.
Like I said, I'd be perfectly happy with a tag file somewhere in the directory tree. Or some similar mechanism.
Okay, a quick question. Do you have a *.cabal
file at the root of your ghcjs part? Do you depend on ghcjs-base there?
That's a great idea. Yes to both questions. However I think there's still a snag. It's possible to build GHCJS-based projects with GHC using webkitgtk. I've never done that, but I'd bet ghc-mod still works in that case. The more I think about, a tag file might be the most reliable way to do this.
A "tag file" would also work in scenarios where you're using a custom build of GHC for a particular project and don't want to disable the atom-haskell plugins globally.
Okay, so v1.12.0 will silently drop all ghc-mod commands if it finds .disable-ghc-mod
file in the local root directory (nearest one to current file that contains *.cabal
file). It's a rather dirty hack, to tell the truth, but it seems to work well enough.
Wow that was amazingly fast! Thank you!
It's a rather dirty hack, to tell the truth, but it seems to work well enough.
Well it's not too far from what many packages do by having a .my-package-config.json
file in the root of the project. You could make it more official by just having something like .atom-haskell-config.json
and requiring a line like {'disable-ghc-mod': true}
.
Oh, I'm not talking about the general idea here when calling it a dirty hack. I'm talking about implementation detail. If it would be enough to read a file in Atom project root, that would be easier to implement cleanly. But making this context-aware proves a bit harder.
One solution would be to have .atom-haskell-config.json
in Atom project root and require something like
{ "ignore-dirs" : [ "dir1", "dir2" ] }
But that seems clunky at best.
That's a good idea too. The main problem is that ghc-mod is not compatible with various projects, but it's hard to disable just that feature of atom-haskell on a per-project basis (where project corresponds to a .cabal
file).
Problem is, Haskell project is not necessarily the same as Atom project. There has been quite a bit of discussion on the topic back in the day...
Yeah, that's understandable. You could have many stack.yaml
and .cabal
files in an Atom workspace.
Just wait for hpack! 😁
@lierdakil You are the 💣 ! Works like a charm. 😄
Letting you know that since haskell-ghc-mod-1.15.0 .disable-ghc-mod
will not work anymore. Instead, see https://github.com/atom-haskell/haskell-ghc-mod#advanced-configuration
TL;DR create .haskell-ghc-mod.json
in project root with following contents to replicate the behavior of .disable-ghc-mod
:
{ "disable": true }
Even better!
I suppose I can close this, since issue seems to be resolved.
I have a project that uses both GHC and GHCJS. The GHC half works wonderfully with this package, but as soon as I open a file from the "frontend" folder (which uses GHCJS) I get endless streams of ghc-mod-related errors. Because of this, I can't reasonably use this plugin at all since it makes editing the front-end too difficult. For now, I think the best we could do would be to conditionally disable all ghc-mod-related code in certain scenarios. Detecting GHCJS would be nice, but as a stop-gap, I could even add a
.no-ghc-mod
file to the root of my front-end directory or something.