[ANN] Pre-release VSCode-Haskell 2.0.0

Announcements
1

How to install pre-releases: vscode-docs/v1_63.md at vnext · microsoft/vscode-docs · GitHub
Note: For now, only VSCode marketplace users can download the pre-release. VSX marketplace will follow soon!

We are happy to announce a Pre-Release for the new major version release for the VSCode Haskell Extension!

Many developers have contributed new features, and this announcement tells you about the latest and greatest changes!

Previously, VSCode downloaded new HLS binaries automatically. The big new exciting change is that we now use GHCup and can manage the following Haskell Tools for you: HLS, GHC, stack and cabal. To install HLS binaries automatically, make sure you have ghcup installed!

The first time you use the new Extension you will be asked whether you want to manually manage your Haskell Toolchain binaries or GHCup should take care of it as it sees fit.

The choice you have:

  • GHCup: Choose this if you don’t want to worry about HLS binaries, etc…
  • PATH: Choose this if you need tight control over which tools you have installed. Nothing will be installed

However, you don’t have to choose between extremes! You have fine-grained control over which tools GHCup is allowed to install/manage.

Summary of Changes:

  • GHCup can now be used for managing all Haskell Toolchain binaries automatically
    • This requires a pre-installed GHCup
    • This is now the only option for managing binaries/HLS automatically
  • The following flags have been removed:
    • updateBehavior
  • The following new settings are available:
    • manageHLS: Do you want ghcup to manage HLS installations for you or use system PATH?
    • ghcupExecutablePath: Set here the path to ghcup if it non-standard
    • Other settings include:
      • toolchain, upgradeGHCup, releasesURL, metadataURL (refer to the VSCode settings for more details)

What this Pre-Release essentially enables us to do is to avoid $PATH issues, and we can manage the pre-built binaries more efficiently and correctly.

If you have issues with VSCode picking up the ghcup executable, you can either set ghcupExecutablePath to the full binary path or explicitly set PATH variable in VSCode:

"haskell.serverEnvironment": { "PATH": "${HOME}/.ghcup/bin:${PATH}" }

Since this is going to be very much a breaking release, please expect bugs and rough edges we have to iron out! Please report all issues you encounter at the vscode-haskell issue tracker or reply to this post :slight_smile: We ask you for your feedback, especially documentation wise: What do you think needs more explanations and what feature is harder than necessary to use or debug.

We thank all our contributors for making this release possible:

  • Julian Ospald
  • Fendor
  • jneira
  • Benjamin M
  • PCloud
  • soiamsoNG
  • Simon Michael
13 Likes
2

Erm, can you guys please add some toolbar buttons a la Haskelly? That’s deprecated, but Haskelly is still a must install due to the toolbar buttons (Load present file in GHCI, Run File, QuickCheck)

3

Hi!

While this is obviously nice to have, the LSP specification has no such run buttons, running tests, etc… and we try to implement features in HLS which follows the LSP specification.

It is possible to add those buttons, but it comes with its fair share of challenges.

  • How to build projects?
  • How to test projects?
  • …

We currently rather focus on stability and correctness in HLS.

2 Likes
4

I guess it’s on my to-do list, then, setting up VSC buttons for Haskell.

5

The extension pre-release has been published to VSX now!

1 Like
6

I was wondering if there are any advantages for me to use VSCode with Haskell over, say, Emacs? Not looking to start an rwar here. I am genuinely curious.

7

Don’t want to hijack the topic here but I’ve switched to VS code from spacemacs a while ago.
This was mainly because the HLS integration seemed much easier.
I was highly sceptical of VS code at first (especially since the VIM-simulation/extension is good but has quite a few warts IMHO) but over time I used Code more and more / Emacs less and now I usually don’t even bother to install Emacs any more … :man_shrugging:

1 Like
8

Both lsp-mode and eglot are pretty complete IME, so not really;
especially if you’re already comfortable with Emacs and/or it has
consumed the rest of your life :slight_smile:

1 Like
9

I have heavily modded my Emacs, and even use Evil mode that I switch in and out of! Also, my Emacs is integrated with LaTeX, which I also use heavily, along with OrgMode – which I just integrated with LaTeX over the past couple of days.

I can now get beautifully-typesetted PDFs – with equations and charts! – with just a keystroke.

I do not look forward to replicating the years of tooling I’ve done with Emacs in VS Code or any other IDE, unless it has things so tremendous to offer that it will blow everything I’ve done with Emacs totally out of the water.

Thanks for the input. Over the past couple of decades I’ve been in and out with Emacs, and tried Eclipse, RubyMine, and a couple of others. I always kept coming back to Emacs, and now I am here to stay.

I would love to see Emacs handle multi-threading. That would be sweet. But not a show-stopper for me, as there are work-arounds.

10

Oh thank god! When I upgraded to the pre-release I was very surprised & though this interface had already existed and only popped up because of a bug. I use NixOS and like to manage GHC & packages myself, but the HLS auto-downloads were nice.

11

You’d want the following config then:

{
  "haskell.toolchain": {
    "ghc": null,
    "cabal": null,
    "stack": null
  }
}
1 Like