__color__,__group__,ticket,summary,component,version,milestone,type,owner,status,created,_changetime,_description,_reporter
3,Active Tickets,1,keep a single GHCi/GHC API session for each project,---,,,defect,claus,new,2009-04-08T10:50:09Z+0100,2010-06-22T17:47:11Z+0100,"Due to Vim not providing a standard API for keeping connections to external tool sessions running in the background ([http://vimdoc.sourceforge.net/htmldoc/develop.html#design-not :help design-not]; this is my main gripe with Vim), haskellmode currently uses tools like `ghc`, `ghc-pkg` as short-term filters.
In theory, it is possible to work around this Vim limitation, but this raises issues of portability (eg, Vim's client-server communication relies on GUI access, so it won't work in a terminal-only situation), complexity (the most promising approach would be to communicate via sockets), dependencies (several of Vim's plugin script languages support asynchronous subprocess control, but which one to depend on - python/perl/..?), and stability (Vim supports dynamic linking, so one might try to use Haskell's own facilities via FFI, but any bugs there can bring down the Vim session).
On recent machines, the short-term filter approach is just fast enough, but it is a waste, and doesn't scale to large projects (workaround: compile all modules, so only the currently edited module will need to be interpreted).",claus
3,Active Tickets,12,set makeprg=cabal\ build?,---,,,defect,haskellmode,assigned,2009-07-29T13:28:11Z+0100,2010-06-22T17:52:30Z+0100,"Any use for this sort of thing anywhere?
{{{
function! SetToCabalBuild()
if glob(""*.cabal"") != ''
set makeprg=cabal\ build
endif
endfunction
autocmd BufEnter *.hs,*.lhs :call SetToCabalBuild()
}}}
I haven't tried to use the Haskell vim scripts yet, so apologies if it's redundant. I just noticed that the makeprg stuff seems to only have examples for GHC.
",kowey
3,Active Tickets,25,HpasteIndex broken because of new hpaste.org structure,---,,,defect,claus,new,2011-10-29T18:15:00Z+0100,2011-10-29T18:15:00Z+0100,"HpasteIndex fails to parse hpaste.org because of new hpaste.org structure.
Patch attached.",lbolla
3,Active Tickets,28,_T sometimes incorrectly removes spaces,---,,,defect,claus,new,2014-01-23T16:41:51Z+0000,2014-01-23T16:41:51Z+0000,"I inserted a really long type signature that included the string ""Field DataTable"" and discovered that it had removed the space and inserted ""FieldDataTable"", which of course generates a compile error. Instead of trying to compact long type signatures by removing spaces, I would suggest formatting them more liberally on multiple lines.",mightybyte
3,Active Tickets,2,use dedicated GHC API client,---,,,enhancement,claus,new,2009-04-08T11:04:10Z+0100,2009-04-29T21:26:36Z+0100,"So far, the features `haskellmode` needed have either been available, or made useful additions to existing tools such as `ghc`, `ghci` and `ghc-pkg`. There comes a time, though, when new features may not fit into existing tools.
One example is getting type information for local definitions/parameters/subexpressions: the feature itself would fit right into `ghci`, but it isn't easy to come up with a good user interface for it in a terminal-based frontend (source location? path of binders to subexpression?). In editor-style frontends, cursor- or mouse-position make natural interfaces for this feature.
It would be good to factor out useful features into a `GHC API` client library, which would then be used by `ghci`, `haskellmode` (for `Vim` and `Emacs`), and other IDE-style tools.",claus
3,Active Tickets,17,add more default locations for documentation installations,---,,,enhancement,claus,new,2010-06-22T18:19:48Z+0100,2010-06-22T18:36:05Z+0100,"It is astonishing how GHC/Haskell installation layouts differ across platforms. I was hoping for GHC to implement [http://hackage.haskell.org/trac/ghc/ticket/1226 `--print-docdir`] and thereby to provide programmatic access to its documentation. This was implemented, but later reverted, as [http://hackage.haskell.org/trac/ghc/ticket/1880#comment:5 it seems unclear how to do it right], so we are back to square one.
Our fallback is to provide a list of common documentation installation locations and, finally, for the user to tell us where the docs are (`g:haddock_docdir`).
This ticket is a place for users to suggest known default documentation installation locations.
As a minimum, we'd need the GHC/Docs installation layout for your packaging system (of course, GHC is in `/tuesdays/odd_languages/GHC-/`, GHC docs are always in `/if/you/really/want/to/know/-GHC-/`, while cabal package docs are in `/the/package/manager/also//cabal////html/`) but for some reason, I find these standard locations hard to guess, so I need you to tell me;-)
Better would be some kind of system (what are the rules for packaging software on your platform?) or Haskell-tool access (e.g., cabal package docs can be found via `ghc field haddock-html`, but how do I find the GHC docs if I know the GHC binary location?).",haskellmode
3,Active Tickets,23,think about explicit logging/debug output,---,,,enhancement,claus,new,2010-11-22T16:07:20Z+0000,2010-11-22T16:07:20Z+0000,"Originally, the plugins gave just enough feedback to let users know what was going on internally.
With the addition of higher-level features, this has lead to two issues:
1. low-level feedback is not appropriate in all higher-level uses (type-balloons don't even call out to ghci anymore, users don't want to see messages not directly related to what they are working on). So some of the feedback has disappeared.
2. `:debug` helps, but having a log of more extensive feedback would help to pin down problems more quickly, especially if it could be saved and sent with bug reports from platforms I don't have access to.
It would be nice to go through all plugin feedback and decide whether it (a) should remain, as it is relevant to plugin use or whether it (b) should be moved into optional output (debug/trace mode), as it is mostly for looking under the hood. The output of (b) could then be enhanced, and recorded/logged, as it would only be seen by people looking for it.
related things to look into: `:echomsg` (`message-history`), `g