Intergrate company-mode or auto-complete

[ShadowCreator]

Both are auto-completion extensions for Emacs and having decent integration with them would improve productivity

https://github.com/auto-complete/auto-complete

https://github.com/company-mode/company-mode

[hvr]

see also #178

[vagifverdi]

(require 'auto-complete)

(defun my-ac-haskell-mode ()
  (setq ac-sources '(ac-source-words-in-same-mode-buffers
                     ac-source-dictionary
                     ac-source-etags
                     )))

(add-hook 'haskell-mode-hook 'my-ac-haskell-mode)

(defun my-haskell-ac-init ()
  (when (member (file-name-extension buffer-file-name) '("hs" "lhs"))
    (auto-complete-mode t)
    (setq ac-sources '(ac-source-words-in-same-mode-buffers
                       ac-source-dictionary
                       ac-source-etags
                       ))

))

(add-hook 'find-file-hook 'my-haskell-ac-init)

[gracjan]

This issue report was last updated in 2013. Is it still relevant to current code state?

[gracjan]

@geraldus: Is this issue describing what you are working on?

[geraldus]

Yeah, but I'm very limited in time :(
Also, integrate means dependencies, and my current goal is separate packages (backends) for company and AC, built on top of some common functionality from haskell-mode (this is step 1 I'm currently working on).

[hvr]

@geraldus btw, are you by any chance also tackling the issue of asynchronous lookups as you mentioned in #178 ?

[geraldus]

@hvr I hope I can tackle this. First of all I need to finish functions which grabs prefix and its context, this information will be used further in completion function (I'm almost done with it, and currently making some final polish).

I'm still need some research, but I suppose the best way to get synchronous completions is to search them in tags, rather than ask REPL (or maybe select tags if REPL is busy or there is no active haskell process). Also I want to use dabbrev--find-all-expansions function in case it is not possible to get completions from REPL or TAGS, which will also give completions for arbitrary words in string literals and comments.

[hvr]

The benefit of asking the REPL is that it knows what's in scope, and maybe in the future we may be able to ask the REPL (or maybe ide-backend -- haven't looked at it yet) to give us more context-aware completions for a given location, all stuff that require more meta-information to be known about the symbols you want to offer completions for.

[geraldus]

I agree with you (and I've have not looked at ide-backend too). But, there are some caveats:

1. it is possible, that user does not use interactive-haskell-mode and REPL is not running.
2. REPL does not provide completions for things defined in let blocks (this is why we also need dabbrev stuff).

As for ide-backend if I'm not mistaken FPco IDE is powered by it, and it will be very nice to make Emacs experience a bit closer to FPco IDE. I'm going to play with it, but I want to finish some tasks for plain haskell-mode without extra tools such as GHCi-ng, ghc-mod, and etc.

[gracjan]

REPL may also be hanging because currently same repl session is used both for arbitrary user interaction and completion commands. That mean sync completion may hang whole emacs and async completion may not return obvious expected results.

So REPL is the way to go, but needs to be handled more carefully.

[geraldus]

@gracjan btw, is there a way to check is REPL currently busy or idling?

[gracjan]

There is no reliable way to do that. There are hacks, some more hilarious
than others. Standard comint mode decides that a shell-like session is busy
if the cursor is in the first column and ready to accept input if cursor is
at the end of a non-empty line (presumably prompt).

This is very fragile. That is why we have whole industry of more
request-response interactions like ghc-mod, ide-backend, ghci-ng, ghcid and
probably others I haven't heard about.

Would be great to split command and interactive channels inside ghci. Would
be even better if command channel had a defined command/response separator.