search

ndmitchell / ghcid

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

Component Selection #297

Closed fosskers closed 4 years ago

fosskers commented 4 years ago

Hi there, I'm a working Haskeller and use ghcid every day. It really improves my development experience, so I can't thank you enough for it.

ghcid can get confused when loading projects that have more than one Main module, say from having multiple executable sections, or even just a single exec and single test-suite. To get around this, I do:

ghcid --command "stack ghci --ghci-options=-fno-code --ghci-options=-fno-break-on-exception --ghci-options=-fno-break-on-error --ghci-options=-v1 --ghci-options=-ferror-spans --ghci-options=-j -- foo:lib foo:test:foo-tests"

The plethora of options I had to borrow from ghcid's source code, since if you offer a custom --command, all of those are lost (relative to what a vanilla ghcid call loads on a simple project). I don't like this approach because it isn't as scalable, and also is at risk of drifting from what ghcid intends with the flags it would otherwise load itself.

My question is this: can we extend ghcid to offer the following usage?

ghcid foo:lib foo:test:foo-tests

where otherwise all the defaults are loaded? From ghcid --help I see that it can natively accept a single Module to load, but here I'm looking to load an entire component while avoiding arcane invocations.

Please and thank you. I'm willing to help with such a PR if pointed in the right direction.

ndmitchell commented 4 years ago

Note that passing all those arguments isn't necessary. Ghcid will work without any of them, and will work almost identically without most of them - it tries to set those arguments once Ghci starts up, and in most cases will do so successfully. But you certainly do get a slightly better experience with them!

I think supporting those : including patterns is a great idea! A PR would be most welcome. Currently Ghcid takes a list of modules to load, where the things are either modules or files (both Stack and Cabal treat them roughly the same, since underlying Ghci does). The code to do so should be in https://github.com/ndmitchell/ghcid/blob/master/src/Ghcid.hs#L134-L162. I'd probably take the approach of partitioning the arguments into fileArgs and componentArgs, and in each case treating them "the right way". E.g. for Stack, if you have components you should do a command line much like you have above. Only wrinkle is that C:\Foo.hs is a file not a component, but the rest should be not too bad, albeit requiring quite a large combination of types of arguments vs stack vs cabal combinations.

fosskers commented 4 years ago

I have a distant memory of things not working the same when I had only specified the components to load, and not all the extra args. But perhaps that changed (or I was wrong), and I've just been cargo-culting the above incantation around unnecessarily.

Okay, I'll see what I can do about this.

ndmitchell commented 4 years ago

See #302 which does some of this with the --target flag. Only wrinkles are its a flag and not arguments being treated simply. It's also a single target rather than multiple (although I have no idea if Cabal supports multiple underneath). CC @Gabriel439.

fosskers commented 4 years ago

I just noticed your announcement on twitter. Yes this is what I was looking for, albeit for stack.

ndmitchell commented 4 years ago

Cool - adding the feature to Stack just be a couple of lines at most, within 10 lines of where the change was made to Cabal. PR most welcome.

fosskers commented 4 years ago

I have it scheduled in my TODOs.