[WIP] Support internal prompts

[fice-t]

Some people do fancy stuff with the prompt (e.g. multiline, colouring).
This offers some support for it.

The haskell-interactive-mode-prompt-previous/next used the prompt regex
to search for the prompt, but this doesn't work with variable
prompts (i.e. containing module names). Now they use text property
search.

Closes #1353

[fice-t]

@Pitometsu Can you see if this works for you? You also need to evaluate this:

(setq haskell-interactive-use-interactive-prompt nil)
(setq haskell-interactive-prompt "FunnyPrint.prompt \"λ \" \"%s\" \" ¬\nλ > ")

[gracjan]

Please use haskell-string-literal-encode here, it can handle escapes the Haskell way.

[gracjan]

We need to have automated tests for all of this functionality. People get offended very much if their colors stop working. There is some infrastructure for external interaction testing in https://github.com/haskell/haskell-mode/blob/master/tests/haskell-test-utils.el#L134 and with examples in https://github.com/haskell/haskell-mode/blob/master/tests/haskell-mode-tests.el#L577 .

[gracjan]

@fice-t, I understand next to nothing out of this, I just hope you can get this right :)

[fice-t]

I guess that depends on what you call 'right'. I think this way of having an extra defcustom, while not ideal, is better than the alternative solution (that doesn't use an extra defcustom) I have on my local branch for a few reasons:

1. My other code uses this method to work around GHCi's lack of ability to redirect :show output. This code has to be formatted in a highly unreadable way so that GHCi parses it right.

2. As I said above, it would break a couple features.

@gracjan Would you object to a manual parsing of their GHCi init file on the Elisp side? I was hoping to avoid that method, but it might be better than the alternatives.

[gracjan]

@fice-t, finding the .ghci might be a problem. Remember that GHCi is started from cabal or stack and it is hard to know what those are doing.

[fice-t]

Even if it's started from cabal or stack doesn't it still use, by default, the same init file? So there should only be 4 places to check according to the manual. And if people need a different one we could just make it a defcustom.

[Pitometsu]

With stack it really may be in other place. For example, I use it as

# stack.yaml
ghc-options:
  "*": -ghci-script .ghci_conf

Because otherwise stack override some .ghciconf values.

[fice-t]

@Pitometsu Doesn't -ghci-script append to the default GHCi init file rather than replacing it? This would mean that nothing special would have to be done on the Emacs side.

Does putting your prompt and prompt2 info in your regular GHCi init file not work with stack with your other settings?

[Pitometsu]

@fice-t well, it depend. let, :def! and :set -package bindings from the usual general .ghciconf overriden. But :def bindings works. Also if I call something like :setupmyprompt at the end of usual .ghciconf it overriden by stack as well. So I forced to call custom .ghci_conf explicit specially for stack.

---

UPD: also I have for this purpose:

;; custom.el

;; ...
 '(haskell-process-args-cabal-repl
   (quote
    ("--ghc-option=-ferror-spans" "--ghci-options=\" -ghci-script .ghci_conf\"" "--with-ghc=intero")))
 '(haskell-process-args-stack-ghci
   (quote
    ("--ghc-options=-ferror-spans" "--ghci-options=\" -ghci-script .ghci_conf\"" "--with-ghc=intero")))
 '(haskell-program-name
   "stack ghci --ghci-options=\" -ghci-script .ghci_conf\" --with-ghc=intero")
;; ...

[Pitometsu]

But if you intend to set prompt interactively after ghci loaded, it doesn't matter.

[Pitometsu]

@fice-t So in general .ghciconf user can create function via :def for prompt, but for stack it can be enabled either interactively or at custom script.

[Pitometsu]

@fice-t sorry, have no ability to check your PR for some time. And now could help with testing it. Please, point me, if I can check something.

[Pitometsu]

Any updates here?

[Pitometsu]

@fice-t any updates? :)