Wrong completion-at-point in Haskell interpreter with helm

[issue-dispenser]

Suppose you have a folder structure like so:

• ~
  • top
    • mid1
    • mid2
      • bot

and you start the interpreter inside ~.

With the prompt :cd top/_ and with _ as the cursor, doing haskell-interactive-mode-tab (or (completion-at-point) as that's what it actually uses) gives a selection for helm between top/mid1/ and top/mid2/.

Selecting the latter then yields:
:cd top/top/mid2/

It seems that the selection candidates shouldn't include what's already written, at least when working with helm. For reference, doing the same thing in eshell:

Starting at cd top/_ and doing (completion-at-point) shows mid1/ and mid2/ as selections and yields:
cd top/mid2/

Another thing that I found out while testing this was that sometimes (inconsistently) whatever haskell-interactive-mode-tab uses for its selection doesn't update by itself. For instance, starting in ~/:
:cd top/
:cd _

Pressing tab here behaves as if it was in the ~directory, not in top. If you instead have a valid starting letter (e.g:cd m_ in this case), then it seems to expand consistently.

[geraldus]

Can you please inspect and post here values of completion-at-point-function variable for both REPL buffer and eshell buffer.

[issue-dispenser]

In REPL: (haskell-interactive-mode-completion-at-point-function t)
eshell: (pcomplete-completions-at-point t)

[geraldus]

@issue-dispenser thanks, using company as my completion backend I did not meet this issue, it looks like we should do some extra work for helm.

[gracjan]

@issue-dispenser: you seem to know what you are doing and to know Emacs. Can you help us with this and submit a pull request?

[geraldus]

Yeah, join in! (:

[issue-dispenser]

You overestimate me, but I still might be able to do something.

I found the secondary issue (easy one) in haskell-interactive-mode-completion-at-point-function:

(if (string= inp (car-safe haskell-interactive-mode-completion-cache))
          (cdr haskell-interactive-mode-completion-cache)

This assumes that if you have the same partial input (in this case :cd) that the completion should be the same. This is of course wrong when commands like :cd change the state of the REPL (its pwd).
I'd say that this means that the cache should be removed as it doesn't guarantee anything. Or would you rather maintain a list of 'volatile' functions/inputs at which it would override the use of the cache?

[gracjan]

This cache thing is an interesting find... I did not know we have it there.

Anyway a cache without a solid invalidation scheme is a source of issues.

Can you remove haskell-interactive-mode-completion-cache variable and everything that tries to use it?

[gracjan]

@issue-dispenser: Can I assign this issue to you? We will see how far you will get.

[issue-dispenser]

I can get rid of the cache.

However, I can't seem to find the cause of the main issue. When completing :cd to in the ~ directory, the result of haskell-interactive-mode-completion-at-point-function is (313 315 (top/)), where 313-315 contains to. The result after completion is :cd top/, meaning to was correctly replaced with top/

When completing :cd top/ the result is (313 317 (top/mid2/ top/mid1/)) and after completion the prompt becomes :cd top/top/mid2, meaning top/ wasn't replaced with /top/mid2/, but it was concatenated with it for some reason.

The result seems to comply with completion-at-point-function's rules (START END COLLECTION), so I don't know what the issue is. Apparently the function can also include a property list for 'additional information', but I'm not sure if that would help.

[issue-dispenser]

Maybe the issue is on helm's side after all (not sure why eshell's completion was different). Apparently completion-at-point calls completion-in-region on the result, and that works fine without helm, but when helm-mode is active that gets replaced with helm--completion-in-region which looking at the source does a lot of stuff I don't understand.

Edit: Just tested in a scratch buffer and indeed, the issue is on helm's side. I'll open an issue there.
Edit 2: Apparently there's already a helm PR in progress that fixes the issue, so that's good news.

[gracjan]

Can you link the relevant helm PR here? (And thanks for digging into this issue).

[geraldus]

Phew, great. Also, I can't remember that I did anything to completion cache, likely is it a heritage from past times.

[issue-dispenser]

It's emacs-helm/helm#1357