Feature request: support REPLish workflow

[ethercrow]

I wonder if a typical ghci workflow can be automated with sos.

Usually you run a ghci process and:

1. When *.hs changes, you send :r<CR> or possibly :r<CR>:main<CR> to ghci
2. When *.cabal or *.yaml changes, you restart ghci
3. Also you're able to type stuff into currently running ghci

Right now 2. is working perfectly, 3. works kind of weird (I'm not even sure how to describe it) and 1. is not covered at all.

Meanwhile, ghcid supports 1 and 2, but not 3 (by current design) and naturally only supports ghci. Ideally I'd like to be able to use sos to automate a REPL workflow for any language, e.g. restart the process on project.clj changes and send (run-all-tests)<CR> on other changes.

[schell]

This is a good idea.

[jappeace]

Instead of focusing on making a repl work, how about making any shell work (since a repl is just a shell). I want something similar but execute stuff in a nix shell instead.

Something like:

commands: 
   - shell: ghci
     command: :r 
     invalidate: *.yaml *.cabal
   - shell: nix-shell
     command: cabal new-build -j --ghc-options --no-code
     invalidate: *.nix

[schell]

Oh wow that's a great idea! I could use that at work.

[jappeace]

I've been thinking about this, but getting this to work in just native Haskell maybe hard. What you want is having the shell running in the background and then be able to write input to it and intercept the output.

Now the output isn't hard as it's just a stdout file handle. But the input is more problematic, see: https://serverfault.com/questions/178457/can-i-send-some-text-to-the-stdin-of-an-active-process-running-in-a-screen-sessi/547144 You can write to the stdin, but it bypasses the program. In other words, the shell doesn't process the command send to stdin.

The solutions offered are either the screen command, or use tmux, for which a client exists: http://hackage.haskell.org/package/chiasma. In any case it would depend on external programs.

Maybe tmux is the right approach as this project shouldn't be doing shell management itself?

Any thoughts?