ide-haskell – GUI and minimal utilities ABSOLUTELY REQUIRED!.language-haskell – Syntax highlighting and Haskell autodetection ABSOLUTELY REQUIRED!.If you decide to stick to your own linter and build tool support, I just hope you'll make it simple to disable them, so users like me can use alternatives while still enjoying the other features of ide-haskell (like type lookups).The Atom-Haskell packages assume that you have at least a minimal Haskell toolchain installed on your system. Totally understand your concerns about the burden of dependencies and having to keep up with their breaking changes, though, so it's just a suggestion to consider. There is already IMO a good abstraction layer for doing this in the community that many languages make use of. My point here, in reference to the subject of the ticket, is that ide-haskell would now probably be considering how to share code to do these things with two different tools, cabal and stack. They will expose "targets" (which could specifically be the project's build targets, but also auxiliary tasks like configure) and then the user can quickly open a palette and run their choice of them.
More on topic, providers written for the build package can have flexibility to run much more than a build command. Sorry to stray off topic with the question. Is there a straightforward way to disable it? I don't see an exposed config setting. That's just it-personally, I do want the type hints and such that ide-haskell provides, but I'd rather not use its linter functionality. I only provide linter support for folks who don't want that extra functionality. type/info tooltips are shown by ide-haskell as well. Ide-haskell has a wider scope than that of linter. Would be nice if the two packages had a clear separation of responsibility on this so that linter preferences could be handled in one place, whether using output from ghc-mod, hlint, or both. Turning this on results in clashing tooltips if you have ide-haskell tooltips enabled, which is a rather clunky and confusing experience. Perhaps this has been discussed elsewhere before, and maybe something like ide-haskell-cabal has a wider scope than what providers for the build package can do, but it might reduce the code that has to be maintained for ide-haskell and its backends, and personally I like the uniform user interface that these packages provide across work in different languages (consistent UI & consistent mappings without needing a bunch of scoped config overrides).Įdit: Actually haskell-ghc-mod can also lint on save and provide lint results to linter. This may be somewhat of an aside, but while we're on the topic of multiple build backends and adding a new one… is it worth thinking about instead shipping providers for the build package (and while we're at it, maybe the linter package instead of ide-haskell's homegrown one)?
0 kommentar(er)
