Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a way to make ghc-mod's execution directory customizable #12

Merged
merged 1 commit into from
Jul 6, 2012

Conversation

adimit
Copy link
Contributor

@adimit adimit commented Jul 5, 2012

This allows us to modify from where ghcmod is executed. Always executing
it from the folder the current file resides in can cause problems with,
for example, Yesod's scaffolding, where some of the splices expect files
to live in certain places relative to the compiler's working directory.

To explain, consider the following: use yesod init to create a new default Yesod project, and cd to the new project's directory. Then:

% ghc-mod check Settings/StaticFiles.hs
# no problems reported
% cd Settings
% ghc-mod check StaticFiles.hs
# returns: StaticFiles.hs:1:1:Exception when trying to run compile-time code:  static: getDirectoryContents: does not exist (No such file or directory)  Code: staticFiles staticDir

Making it possible to set ghc-mod's working directory explicitly allows the user to use Yesod's default scaffolding with ghcmod-vim. There might be another fix, but I can't think of any.

This allows us to modify from where ghcmod is executed. Always executing
it from the folder the current file resides in can cause problems with,
for example, Yesod's scaffolding, where some of the splices expect files
to live in certain places relative to the compiler's working directory.
@eagletmt
Copy link
Owner

eagletmt commented Jul 6, 2012

I'm not familiar with Yesod, but doesn't it generate a cabal file?
ghcmod-vim has a mechanism to automatically detect the cabal file and set the suitable working directory (see ghcmod#build_command() https://github.com/eagletmt/ghcmod-vim/blob/master/autoload/ghcmod.vim#L351).

@eagletmt
Copy link
Owner

eagletmt commented Jul 6, 2012

I'm sorry, I have misunderstood what is the problem.

But I don't think it is a good idea to set a global variable.
I suppose it should be a buffer-local setting.
Anyway, I will merge your commit and maybe I will add some fixes.
Thank you.

eagletmt added a commit that referenced this pull request Jul 6, 2012
Add a way to make ghc-mod's execution directory customizable
@eagletmt eagletmt merged commit 1c5fcb4 into eagletmt:master Jul 6, 2012
@adimit
Copy link
Contributor Author

adimit commented Jul 9, 2012

Sorry I didn't write the last four days, I was terribly busy!

Yes, a buffer-local setting might be a better solution, since you might have different projects open in the same vim session. The documentation would have to be updated to direct the user to set something like

au FileType haskell let b:ghcmod_use_basedir = getcwd()

I could send a patch if you'd like.

@jgreene
Copy link

jgreene commented Aug 17, 2012

I've been trying to use ghcmod-vim with yesod and I'm getting errors like the above. I've pulled the latest and tried:
au FileType haskell let b:ghcmod_use_basedir = getcwd()
in my .vimrc. Is there something else I'm missing?

@adimit
Copy link
Contributor Author

adimit commented Aug 17, 2012

Have you started Vim from the root of the scaffold site? I.e., instead of doing something like cd Handler; vim Home.hs, you just do vim Handler/Home.hs. If you're starting Vim from the file browser it'll probably not start in the project's root directory and you need to issue something like :cd .. (as a Vim command) in order to change the current working directory. You can find out Vim's working directory with :pwd.

@ghost
Copy link

ghost commented Feb 3, 2013

Why not do what ctrlp does: if there exists a .git directory somewhere consider it as the root ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants