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.
Do you mean, when importing a datatype Foo, the code action should be result in a line:
import Data.Foo (Foo(..))?
We should probably make the completions aware of that too. I made a typo, I mean in an export list.
Oh, alright.
I think I understand. Is the fucntoin getCompletions responsible for that behaviour as well?
@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.
I assume so as well. Maybe we can add another context?
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:
ImportContextwith a differentiation between the module to import and import list. E.g.
ImportContext ImportModule: Completion to imprt a moduleImportContext ImportList: Completion to import from the moduleImportContext HidingList: Completions to hide items from a moduleModuleContextComplete 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?
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:
EDIT: maybe hiedb can be useful for this?
EDIT EDIT: hiedb does not help us, since it is not its scope.
Most helpful comment
I assume so as well. Maybe we can add another context?