Skip to content
This repository has been archived by the owner on Apr 25, 2020. It is now read-only.

Does not see a way to customize the ghc or ghc-mod command #664

Open
rongcuid opened this issue Oct 19, 2015 · 2 comments
Open

Does not see a way to customize the ghc or ghc-mod command #664

rongcuid opened this issue Oct 19, 2015 · 2 comments

Comments

@rongcuid
Copy link

Since I am using stack and currently only stack, the command to invoke ghc is actually a script ghc-wrapper which actually executes stack ghc -- <options>. However, I don't see any way to have ghc-mod emacs mode use any of the alternatives. I looked into the customize variables, and tried using ghc-wrapper, which does not seem to work:

ghc-debug:

Path: check if you are using intended programs.
      ghc.el path: /home/carl/.emacs.d/elpa/ghc-20151013.1219/ghc.el
     ghc-mod path: /home/carl/.local/bin/ghc-mod
         ghc path: nil

Version: all GHC versions must be the same.
      ghc.el version 5.4.0.0
     ghc-mod version 5.4.0.0 compiled by GHC 7.10.2
    "ghc" not found

Environment variables:
    PATH=/home/carl/.local/bin:/home/carl/.cabal/bin:/home/carl/Softwares/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/lib/jvm/java-8-oracle/bin:/usr/lib/jvm/java-8-oracle/db/bin:/usr/lib/jvm/java-8-oracle/jre/bin:/usr/lib/jvm/java-8-oracle/bin:/usr/lib/jvm/java-8-oracle/db/bin:/usr/lib/jvm/java-8-oracle/jre/bin

The result of "ghc-mod debug":
Root directory:      (somewhere)
Current directory:    (somewhere)
GHC Package flags:
    -i(somewhere)
    -i(somewhere)
    -global-package-db -user-package-db -Wall
GHC System libraries: /home/carl/.stack/programs/x86_64-linux/ghc-7.10.2/lib/ghc-7.10.2
GHC user options:

Then, all packages imported that are installed in stack is marked error. If I execute this:

$ ghc-mod check Computer.lhs

I get:

Computer.lhs:7:10:Could not find module ‘System.Random.MWC’Use -v to see a list of the files searched for.

While the following works (Well, OK, some warnings):

 $ stack exec -- ghc-mod check Computer.lhs
Run from outside a project, using implicit global project config
Using resolver: lts-3.8 from implicit global project's config file: /home/carl/.stack/global/stack.yaml
Computer.lhs:14:12:Warning: This binding for ‘nS’ shadows the existing binding  bound at Computer.lhs:12:12
Computer.lhs:15:12:Warning: This binding for ‘nS’ shadows the existing binding  bound at Computer.lhs:12:12
Computer.lhs:15:25:Warning: This binding for ‘es’ shadows the existing binding  bound at Computer.lhs:12:15
Computer.lhs:39:16:Warning: Defaulting the following constraint(s) to type ‘Integer’  (Integral a0) arising from a use of ‘go’ at Computer.lhs:39:16-17  (Num a0) arising from the literal ‘0’ at Computer.lhs:39:31In the expression: go (length bs) 0 bsIn an equation for ‘getProb’:    getProb bs      = go (length bs) 0 bs      where          go l n [] = (fromIntegral n) / (fromIntegral l)          go l n (b : bs)            | b == True = go l (n + 1) bs            | otherwise = go l n bs
Computer.lhs:42:19:Warning: This binding for ‘bs’ shadows the existing binding  bound at Computer.lhs:39:11
@rongcuid
Copy link
Author

My current work around is the following wrapper script. It seems to work, though emacs highlights errors on the "literate" part of literate haskell. The highlight problem magically fixed somehow. But I would still like to be able to set the commands directly in Emacs

#!/bin/bash
# ~/.local/bin/ghc-mod

cmd=$1
shift

stack --verbosity silent exec -- ghc-mod $cmd "$@"

@DanielG
Copy link
Owner

DanielG commented Oct 19, 2015

I know this is a workaround that is currently needed for most more complicated stack setups but going forward I would like ghc-mod to handle this for you.

Once we implement #615 this use case should either disappear completely or at least it would become very easy to check if we have to do this workaround instead.

I suppose it would be possible to check if this workaround is necessary and just use it right now, but it is sort of really ugly to have to install one instance of ghc-mod globally (linked against any version of ghc) just so we can use it to dispatch to the right "real" ghc-mod we want to use with a stack project.

So in short I think Elisp is the wrong place for this since, as with every hack we do there, all other frontends also have to implement something equivalent. Leading to even more duplication of logic and effort.

If someone wants to give implementing either of these a shot I'm happy to consider the PR.

@DanielG DanielG added this to the v5.5.0.0 milestone Oct 19, 2015
@DanielG DanielG modified the milestones: v5.7.0.0, v5.6.0.0 May 14, 2016
@DanielG DanielG removed this from the v5.9.0.0 milestone Sep 14, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants