f0bfcb8811
Not doing this makes having GhcModT pretty pointless as users of the library wouldn't be able to use custom inner monads as evey function for dealing with GhcModT's would be constraint to (GhcModT IO) thus only allowing IO as the inner monad. |
||
---|---|---|
elisp | ||
Language/Haskell | ||
scripts | ||
src | ||
test | ||
test-elisp | ||
.ghci | ||
.gitignore | ||
.travis.yml | ||
ChangeLog | ||
ghc-mod.cabal | ||
hcar-ghc-mod.tex | ||
LICENSE | ||
README.md | ||
Setup.hs |
Happy Haskell Programming
Please read: http://www.mew.org/~kazu/proj/ghc-mod/
Using the stable version
Emacs front-end, which is consistent with binaries on Hackage, is available stable MELPA whose URL is http://melpa-stable.milkbox.net/packages/. So, your "~/.emacs" should be:
(require 'package)
(add-to-list 'package-archives
'("melpa" . "http://melpa-stable.milkbox.net/packages/"))
(package-initialize)
With this configuration you can install the stable Emacs front end indicated by "ghc" from MELPA while you can install ghc-mod
/ghc-modi
binaries by:
% cabal update
% cabal install ghc-mod
Using the develop version
You should install both Emacs front-end and binaries from this git repo. If you use the snapshot MELPA to install Emacs front-end, you would suffer from inconsistency between Emacs front-end and binaries.