ndmitchell / ghcid

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

Prioritise `cabal` discovery over `.ghci` #330

Closed i-am-tom closed 3 years ago

i-am-tom commented 4 years ago

Hi!

Firstly, thanks so much for this project; it is an absolute marvel, and has significantly reduced the amount of time I spend staring at builds!

Recently, I had the idea that, for a particular unicode-heavy project, I'd add a .ghci file like so:

:load Text.Show.Unicode
:set -interactive-print=Text.Show.Unicode.uprint

... thus making all the unicode characters show up in the REPL correctly. However, when I run ghcid, I get the following error:

<no location info>: error:
    module ‘Text.Show.Unicode’ cannot be found locally
<interactive>:1:1-24: error:
    Not in scope: ‘Text.Show.Unicode.uprint’

I am certainly not an expert, but I believe the problem is that having a .ghci file makes ghcid assume I want to run a ghci ... command, rather than a cabal ... command:

https://github.com/ndmitchell/ghcid/blob/d6191a111a1160ddecb05292eefe28ae362ccbaa/src/Ghcid.hs#L166-L167

Of course, cabal recognises the .ghci file, so cabal repl would indeed work just fine! So, my question is: is there a potential problem with putting the .ghci guard after the cabal check? Would this break anything? If not, would you mind if I made a PR to swap these round?

Once again, thanks so much for ghcid!

i-am-tom commented 4 years ago

Having said all this, ghcid -c "cabal repl" has a similar problem (presumably not using cabal to resolve module references); is there something more clever going on here? (Regular cabal repl loads the module with no trouble)

ndmitchell commented 3 years ago

Yep, if there is a .ghci file, then ghcid prefers it. The reason is all to do with multiple-home-packages in GHC - see https://mpickering.github.io/ide/posts/2020-10-12-multiple-home-units.html. With Cabal you can only get one package, e.g. the library but not the test suite. As a result, most of my packages (e.g. this one) have a .ghci file which loads them in a way that you can have all packages. As such, I implemented the rule that if you have a .ghci file, it defaults to ghci alone.

However, if you want a specific approach, the best way is to create a .ghcid file, which can have whatever flags you want to give to ghcid - e.g. put --command=cabal repl in the file and it will always pick cabal repl: https://github.com/ndmitchell/ghcid#usage-tips.

There is a question of whether people with .ghci files are usually working around multiple-home-packages, or whether they wanted a few extra features to their Cabal. It's hard to say - but whichever is more popular should probably be the default...

If normal cabal repl loads the module fine, but ghcid -c "cabal repl" doesn't then a --verbose trace would be useful to see what is going on.

i-am-tom commented 3 years ago

Hey! Sorry for taking so long to reply, and thanks for all the info! With a bit of trial and error, it seems that .ghcid does exactly what I need, so I'll close this. Thanks again!