Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] Support internal prompts #1357

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Conversation

fice-t
Copy link
Contributor

@fice-t fice-t commented Jun 6, 2016

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
Copy link
Contributor Author

fice-t commented Jun 6, 2016

@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λ > ")

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.
@@ -104,9 +104,9 @@ You can create new session using function `haskell-session-make'."
":set -v1"
":set +c") ; :type-at in GHC 8+
"\n"))
(haskell-process-send-string process ":set prompt \"\\4\"")
(haskell-process-send-string process (format ":set prompt2 \"%s\""
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@gracjan
Copy link
Contributor

gracjan commented Jun 7, 2016

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
Copy link
Contributor

gracjan commented Jun 11, 2016

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

@fice-t
Copy link
Contributor Author

fice-t commented Jun 12, 2016

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
Copy link
Contributor

gracjan commented Jun 12, 2016

@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
Copy link
Contributor Author

fice-t commented Jun 12, 2016

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
Copy link

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
Copy link
Contributor Author

fice-t commented Jun 12, 2016

@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
Copy link

Pitometsu commented Jun 12, 2016

@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
Copy link

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

@Pitometsu
Copy link

Pitometsu commented Jun 12, 2016

@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
Copy link

@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
Copy link

Any updates here?

@Pitometsu
Copy link

@fice-t any updates? :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants