Detect GHCJS and disable errors

[3noch]

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.

[lierdakil]

I'm not sure how one would differentiate between regular Haskell and ghcjs... I'll see what I can do.

[3noch]

Like I said, I'd be perfectly happy with a tag file somewhere in the directory tree. Or some similar mechanism.

[lierdakil]

Okay, a quick question. Do you have a *.cabal file at the root of your ghcjs part? Do you depend on ghcjs-base there?

[3noch]

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.

[3noch]

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.

[lierdakil]

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.

[3noch]

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}.

[lierdakil]

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.

[3noch]

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).

[lierdakil]

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...

[3noch]

Yeah, that's understandable. You could have many stack.yaml and .cabal files in an Atom workspace.

[3noch]

Just wait for hpack! 😁

[3noch]

@lierdakil You are the 💣 ! Works like a charm. 😄

[lierdakil]

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 }

[3noch]

Even better!

[lierdakil]

I suppose I can close this, since issue seems to be resolved.