Closed jamesdbrock closed 6 years ago
Thanks! I don't use stack, but I am willing to merge this eventually. First I want to wait a bit and maybe hear feedback from other people. As you say, the automatic stack.yaml detection in your patch may break things for existing users
Yeah, the automatic stack.yaml
detection may break things for existing users. I just pushed another commit to the branch which requires users to explicitly opt-in by configuring .vimrc
:
g:hdevtools_stack = 1
So if that configuration option is not set, then nothing changes. That should provide a smooth adoption path for this feature.
I've also got some other commits on this branch which make some orthogonal improvements to the README, I hope you don't mind.
Do you want me to squash these stack feature commits together? What's the etiquette here, clean squashed commits or transparent work process with distinct commits?
This repository is simple enough such that no formal process is needed. I think this pull requests looks good. Should I merge it right now?
I rebased and squashed the stack support commits and cleaned them up, ready to merge now. Thanks for maintaining this plugin @bitc !
Prevent ghc version mismatch between
hdevtools
and the project by usingstack
to invokehdevtools
instead of looking forhdevtools
on the$PATH
, to avoid issues such as https://github.com/hdevtools/hdevtools/issues/78Because
hdevtools
generally needs to be built with the same ghc version as the project being examined byhdevtools
, there is no way to "install" a globalhdevtools
which works for all Haskell projects on a machine. And there is no way to solve this problem by changinghdevtools
. stack and vim-hdevtools together can provide a nice solution to the problem of having a specially-builthdevtools
for each project.Possible problems or further work
Add a configuration option to disable
stack.yaml
detection?