let user decide whether balloneval should be set

[phercek]

The bigger a project is the more annoying ballooneval is. The problem is that such an innocent thing as moving a mouse to an edit location can result in a background load to ghci to find out the type information which freezes vim GUI for a potentially long period. User is left wondering why vim stopped to respond. An easy workaround is to switch off ballooneval but this works well only when it is not set on again during :make. Do not set ballooneval in ghc.vim. Let user decide whether he/she wants it on. He/she can do it in ~/.vimrc. A more complicated option would be to provide something like g:haskellmode_beval to control whether vim haskellmode can set ballooneval on. Here is the simpler solution:

--- ghc.vim.old	2009-09-16 16:18:39.000000000 +0200
+++ ghc.vim	2009-09-16 16:31:18.000000000 +0200
@@ -112,7 +112,6 @@
 
 " show type of identifier under mouse pointer in balloon
 if has("balloon_eval")
-  set ballooneval
   set balloondelay=600
   set balloonexpr=GHC_TypeBalloon()
   function! GHC_TypeBalloon()

[haskellmode]

It isn't ballooneval that is at fault, more a conflict of wanting to query GHCi for the types when needed, and ballooneval being tied to cursor movements. Ideally, the query should run in the background, without disturbing the user, but that isn't the case (and I switched off the messages so the user doesn't know what is happening).

You probably just want to comment out the line in GHC_TypeBalloon that calls GHC_HaveTypes(), as that is responsible for calling GHCi. Then you don't get delays when the types are not available, but you do get type balloons if one of the other commands has queried GHCi for the types (or you can explicitly :call GHC_HaveTypes() to get the type info).

I'll leave this ticket open as the current design isn't right. Will have to think about alternatives.

[haskellmode]

fixed by:

don't trigger GHC_BrowseAll() from within GHC_TypeBalloon, 
as that ties a potentially long-running task to mouse
motion; instead, just point to :GHCReload if necessary.

That avoids the delays, at the expense of having to query for updated type info explicitly. Left a TODO note about optionally reenabling the implicit querying.