search

parsonsmatt / intero-neovim

A neovim plugin for Intero, forked from ghcmod-vim
218 stars 28 forks source link

Current module should be added to current scope #127

Closed stellarhoof closed 6 years ago

stellarhoof commented 6 years ago

Currently, when InteroStart, InteroOpen, etc... are invoked, only the main module is in scope. This is confusing when trying to get the type for a module other than the main one. For example, if I have Main.hs and Parser.hs and invoke InteroStart from Parser.hs, Parser imports won't be in scope, which is probably not what the user intends.

Moreover, it might be a good idea to do the same on BufEnter? I'm not sure if this will have a big impact on performance or it might affect usability.

Alternatively, instead of loading the module, we could also just replace the current ghci scope to contain only that module with (for example) :m + *Parser. This wouldn't work so well for completion (discussion in #5), but we can play around with different settings, any of which I believe would be an improvement.

parsonsmatt commented 6 years ago

The main complication here is that loading a file can potentially be really expensive. Intero will reload and recompile everything that it needs to.

stellarhoof commented 6 years ago

Yeah I agree loading a file can be really expensive, but ghci already does that when it starts. At least in my setup, whenever I stack ghci, all the modules in the project get compiled to bytecode beforehand, because they are "interpreted". At this point, using :m + *Module is inexpensive, since it doesn't do a full load of the file, it just adds Module definitions to the current scope.

matthewleon commented 6 years ago

Adding my voice here to say that the current behavior really tripped me up. It feels unintuitive. I understand the hesitation regarding the demands of loading the file. But this is done async, no?

parsonsmatt commented 6 years ago

Another issue is that file loading in stack projects is best done via setting the relevant target -- otherwise you're going to get weird GHCi flags. Consider an executable with ImplicitPrelude enabled and a library with NoImplicitPrelude. If you load the library as a target and try to :load the executable Main.hs file, you'll get errors due to the GHCi flags used.

Seems like we may want to have two divergent behaviors: one for "I am in a stack project" and another for "there's no stack project, just load the file."

parsonsmatt commented 6 years ago

Closing as a duplicate of #69