search

ndmitchell / ghcid

Very low feature GHCi based IDE
Other
1.13k stars 114 forks source link

Interpret `lint` as a shell command instead of an executable #278

Closed jonascarpay closed 5 years ago

jonascarpay commented 5 years ago

Lint commands cannot take arguments since it's the argument to readProcess, and therefore needs to exactly name an executable. For instance, ghcid --lint="hlint --color" crashes, and this fixes that. That said, I'm not entirely sure if there are any nuances that I might be overlooking that make this a bad idea?

jonascarpay commented 5 years ago

Maybe it's also worth defaulting the lint command to hlint --color

ndmitchell commented 5 years ago

Sounds like a reasonable idea. I'm worried about spaces in file names that we are passing - but maybe any work to quote them is more hassle than it's worth?

I suspect we should pass --colour to HLint only if ghcid detects it should use colour.

jonascarpay commented 5 years ago

I'm worried about spaces in file names that we are passing

That's a good point, although I should be able to reuse this, I think: https://github.com/ndmitchell/ghcid/blob/master/src/Ghcid.hs#L162-L166

I suspect we should pass --colour to HLint only if ghcid detects it should use colour.

That may be a good idea, although it does mean that we make some special allowances for hlint more than it just being the default linter. I'll leave it for now.

ndmitchell commented 5 years ago

Yep, reusing that escaping code makes a lot of sense.

Also makes sense to leave the HLint without colour. To be honest, syntax highlighting of Haskell expressions with colour in HLint seems odd when GHC highlights the bits of the message but not the code. I wonder if HLint colour wants revisiting.

jonascarpay commented 5 years ago

Alright, I rewrote & confirmed this now works with paths that contain spaces.

ndmitchell commented 5 years ago

Thanks!