Added nix-shell-ghci support.

[alexanderkjeldaas]

A 5 minute hack, 95% untested, but I get my ghci prompt.

[alexanderkjeldaas]

It still works. A bit more tested I guess.

[purcell]

Thanks!

Hey @ocharles, you were hacking on something similar -- please can you review/comment on this PR?

[ocharles]

I was doing stuff with ghc-mod, not haskell-mode. I can give this a try though!

[purcell]

(Note this also relates tangentially to #348 and #198, which are about setting the process type automatically where possible, and removing the likely-defunct cabal-dev option.)

[hvr]

like @purcell noted, this may conflict with the current ideas to have haskell-mode do something DWIM-ish that works in 99% of all cases.

[alexanderkjeldaas]

I don't think there's a conflict with #348 (which I submitted because it
was all so confusing to set up, and then I figured that I couldn't get
nix-shell to work out of the box). Some code needs to handle
nix-shell-ghci anyways. The DWIM-ish thing just needs to look at the
evidence and choose between the different modes.

On Wed, Oct 1, 2014 at 6:09 PM, Herbert Valerio Riedel <
[email protected]> wrote:

like @purcell https://github.com/purcell noted, this may conflict with
the current ideas to have haskell-mode do something DWIM-ish that works in
99% of all cases.

—
Reply to this email directly or view it on GitHub
#350 (comment).

[alexanderkjeldaas]

I've added nix-shell-cabal-repl as an option as well.

[alexanderkjeldaas]

updated to HEAD

[purcell]

@alexanderkjeldaas Looks good to me. Please can you redo that last commit now that I've fixed the code which calls locate-dominating-file?

[alexanderkjeldaas]

@purcell Updated to HEAD

[purcell]

Just been reviewing this in detail.

Since this PR adds 2 more process types rather than 1, I wonder if an alternative might be to simply have a custom var which tells haskell-process to execute commands using nix-shell ... --command .... This would result in simpler code, I think, and also allow nix-shell to be used seamlessly in more places.

[alexanderkjeldaas]

Changing haskell-process like that would make the haskell-process-type
auto a bit weird since it should both decide which process type to use,
as well as the default for this new custom var.

So in that case, the auto might be moved out to a separate flag that sets
the other two. Could it be a bit confusing for the user?

On Thu, Oct 16, 2014 at 9:05 PM, Steve Purcell [email protected]
wrote:

Just been reviewing this in detail.

Since this PR adds 2 more process types rather than 1, I wonder if an
alternative might be to simply have a custom var which tells
haskell-process to execute commands using nix-shell ... --command ....
This would result in simpler code, I think, and also allow nix-shell to
be used seamlessly in more places.

—
Reply to this email directly or view it on GitHub
#350 (comment).

[chrisdone]

Since this PR adds 2 more process types rather than 1, I wonder if an alternative might be to simply have a custom var which tells haskell-process to execute commands using nix-shell ... --command .... This would result in simpler code, I think, and also allow nix-shell to be used seamlessly in more places.

Yes, this might be useful to me. For example, I'm using hsenv on some projects and docker on others. I could define a wrapper that would source .hsenv/bin/activate ghci and likewise run-my-docker ghci. E.g.

(defcustom haskell-process-wrapper
  nil
  "A wrapper program to launch the Haskell process defined by `haskell-process-type`.
Nix users may want to use the value (\"nix-shell\" \"--command\"),
Docker users may want to use something like \"run-my-docker\"."
  :group 'haskell-interactive
  :type '(choice string (repeat string)))

This allows us to support Nix and other things without having to special-case them if we don't have to, and you can still put this variable in a .dir-locals.el file for project-specific customization.

[chrisdone]

Also consider that haskell-process tends to run things (e.g. the hasktags support) via GHCi's :!foo syntax, which would mean it would run inside the nix environment (or docker, whatever) automagically.

[purcell]

haskell-process-wrapper

@chrisdone Yes, that's exactly the kind of solution I was picturing.

[ocharles]

In terms of functionality, I can confirm that this works exactly how one would expect :)

[ocharles]

I may have found a bug. haskell-process-cabal-build results in:

error in process filter: haskell-command-exec-go: Wrong type argument: characterp, "shell.nix"
error in process filter: Wrong type argument: characterp, "shell.nix"

[chrisdone]

@ocharles can you write how you're configuring it? I'm not familiar with nix but probably the fix is trivial if I can reproduce.

[ocharles]

@chrisdone The only things I have in my custom-set-variables are:

 '(haskell-font-lock-symbols (quote unicode))
 '(haskell-process-args-cabal-repl (quote ("--ghc-option=-ferror-spans" "-fPIC")))
 '(haskell-process-args-nix-shell (quote ("shell.nix" "-I" ".")))
 '(haskell-process-log t)
 '(haskell-process-type (quote nix-shell-cabal-repl))

Is that the information you're looking for?

[ardumont]

Hello,

I tried something along what @purcell and @chrisdone mentioned.

Here is the full comparison view - https://github.com/ardumont/haskell-mode/compare/add-haskell-process-wrapper?expand=1.

I'm still working on it but the wrapping side works on my side (need to see what's wrong for the default).

I only tested with the nix-shell on my ardumont/haskell-lab project - https://github.com/ardumont/haskell-lab/blob/master/haskell-lab.nix.

Are you interested?

Cheers,

[ardumont]

I'm still working on it but the wrapping side works on my side (need to see what's wrong for the default).

Turns out the non wrapping side works too (just that cabal-repl with a cabal < 16 will not happen :D).

[cocreature]

I think this can be closed?

[ardumont]

Hello, I think so.

tony / @ardumont

On Sun, Feb 15, 2015 at 6:58 PM, Moritz Kiefer [email protected]
wrote:

I think this can be closed?

—
Reply to this email directly or view it on GitHub
#350 (comment).