Completions should be import-aware

[alanz]

If adding a data type that takes a parameter to an import list, the snippet should be empty, and the completion should include (..) if it has subcomponents.

So

  , Foo

Should offer completion of FooBar(..), not FooBar Int or whatever.

[fendor]

Do you mean, when importing a datatype Foo, the code action should be result in a line:
import Data.Foo (Foo(..))?

[alanz]

We should probably make the completions aware of that too. I made a typo, I mean in an export list.

[fendor]

Oh, alright.

I think I understand. Is the fucntoin getCompletions responsible for that behaviour as well?

[lorenzo]

@fendor yes, that should be handled there. the problem is probably that the context given to that function is not enough for it to determine that it is completing an import.

[fendor]

I assume so as well. Maybe we can add another context?

[fendor]

What contexts could be wanted? I'd like to add a bunch of new contexts, to tackle feature request related to that.
I am thinking about:

ImportContext

with a differentiation between the module to import and import list. E.g.

• ImportContext ImportModule: Completion to imprt a module
• ImportContext ImportList: Completion to import from the module
• ImportContext HidingList: Completions to hide items from a module
  May require to add Context information which module is imported.

ModuleContext

Complete automatically module * where with the filename and the path to it.
Complete items in the export list:

• ModuleContext ModuleDeclaration: complete module name.
• ModuleContext ExportList: Offer completions for identifiers in the export list.

---

Is that a good idea? Or should I rather split it into multiple issues and merge them one by one?

[fendor]

I have been hacking a day on that now and adding the contexts and such is easy.
Adding completions for export lists should be pretty trivial as well, just offer all available symbols to export, maybe prefer local symbols.
However, completion for import lists seems to be more complicated:
We do get the completions from all symbols that are currently in scope.
However, if we have an import such as:

import Data.List (find)

Then only find is in scope, thus, we are not aware of other potential symbols.
To circumvent this, we can either:

• always cache all completions and filter for non-import-list completions on symbols that are in scope. Will increase memory consumption considerably in some cases.
• Dont cache this operation and do it on the fly since it might not be that common. Might be considerably slower.
• At last, just dont do it and rely on ghc-mod, hsimport and hoogle to import symbols via code-actions.

EDIT: maybe hiedb can be useful for this?
EDIT EDIT: hiedb does not help us, since it is not its scope.