[Haskell-cafe] What features should an (fictitious) IDE for Haskell have?

[Tony Zorman]

[ I forgot to CC the Haskell Cafe in the first version of this, my
  apologies to Sven for getting this message twice ]

On Tue, Dec 01 2020 16:22, Sven Panne wrote:
> Well, some time ago I actually did, and it was a slightly frustrating
> experience: I'm using Spacemacs, and when I had a look last time, the
> haskell-language-server project was very young, and so was lsp-haskell.el.
> It took quite some time to read HOWTOs/compile/set up things etc., and the
> result was a bit underwhelming: Slow, using tons of memory, buggy, etc.
> Somehow this was to be expected from a new project, nevertheless it was a
> bit demotivating. Although it had a much smaller feature set, I was much
> more happy with Intero, it worked basically out-of-the-box. For most other
> IDEs, setting up a language mode is often just ticking a checkbox or
> pressing a button in an extension manager.

Things are actually much better now, especially for Emacs.  Starting
with Emacs 27, it now uses a proper JSON parser, making LSP operations
much, much faster.  Installation is also a breeze.  For example, eglot
uses HIE by default, so setting it up within Emacs (vanilla, though I
doubt it would be much more complicated for Spacemacs) would just be

    (use-package eglot
      :hook (haskell-mode . eglot-ensure))

If you want to use ghcide instead of HIE, you can throw a 

    (add-to-list 'eglot-server-programs '(haskell-mode . ("ghcide" "--lsp")))

in there somewhere.  The procedure is very similar if you use lsp-mode
instead of eglot.

> Unless things have changed dramatically in the last few months, "easy" is
> definitely not the right word. Using the C++-LSP-Mode in Spacemacs takes a
> one-liner in the config ("Hey, please use clangd as the LSP backend") and
> an "apt install clangd" (if you don't have it already on your disk, which
> is very likely if you do development in C++ on Linux). I had a very
> different experience with Haskell and LSP.

The second part is more of a "why has no-one packaged this for
Debian/Ubuntu derivatives" (which I'm not sure is true anymore, but I
don't use either so I can't check) shortcoming than a Haskell LSP
shortcoming, don't you think?