Add type insertion and info preview.

[johntyree]

This functionality uses the exist type and info features. Type insertion simply
writes the type to the buffer intelligently. Type signatures can be inserted as
by calling ":GhcModTypeInsert".

Info preview uses vim's preview window to display ":GhcModInfo" persistently. It
also allows for several different info's to be displayed at once. The window is
opened by calling ":GhcModInfoPreview". The window is closed and erased on
":pclose".

[eagletmt]

:GhcModInfoPreview works fine, but :GhcModTypeInsert has a problem.
The output from ghc-mod type doesn't contain type class constraints.
For example, if you execute :GhcModTypeInsert on f, you would see a -> m a is inserted.

f x = return x

I suggest to use ghcmod#info() because type insertion is used only for top-level symbols.

[johntyree]

Yes. I noticed that as well. It's a problem for sure and I've complained upstream. I am still working on how to get ghc-mod to report that information in the first place. As it is right now, this feature works in the sense that it inserts the type that ghc-mod reports. We just need ghc-mod to start reporting full type information.

See DanielG/ghc-mod#69.

If you feel like it's a net loss then this patch can just sit around until that issue is fixed upsteam. I still use this feature and add the type-class contraints myself as necessary. For simple functions maybe it's not great, but for complicated types I think it's worth it.

[johntyree]

Maybe I misunderstood. Are you suggesting using info() for type insertion? That could work I guess, after some cleaning.

[johntyree]

Ah I remember now. Info() doesn't work at all unless you are using it for top-level symbols. Sometimes you need to constrain types in smaller throwaway functions inside a where clause, for example. Using type() still works in that case but info() fails.

I don't see why ghc-mod itself wouldn't report the typeclass though. It's just as much a part of the type as anything else.

[eagletmt]

Yes, the info command can be used only for top-level symbols...

Although there is the type-class problem, I think your features are nice. I'll merge your request. Thank you.

[johntyree]

I have a working a version using info() as well. It's fast and does typeclasses but it has it's own problems. For example, it explodes when the identifier is ambiguous, even though you obviously want the implentation that you've just written.

Still, maybe if we could intellegently select between the two implementations based on whether or not it's top-level?

I'll make a dummy pull-request so you can see what I'm talking about.

[johntyree]

#18, for posterity.