Add actions to control the build tool throug hls

[juergenpf]

I'm especially looking at the Visual Studio Code extension ghcide and comparing it to the intero based "older" Haskelly extension.

What I like with the Haskelly extension is its appeal for casual Haskell users or beginners. Haskelly has some smart detection of the project type, and then places proper action buttons in the status bar area that's reserved for that use, like you see in this screenshot

The casual user or beginner often looks for that kind of experience: having a visual editor and simple buttons to build, test and run.

Would be great if you can "borrow" that logic from https://github.com/haskelly-dev/Haskelly

[poscat0x04]

I think this is out of the scope of this project (which is supposed to provide LSP support and some static analysis for Haskell).

[ndmitchell]

To me this is in scope. Although we'd probably want hie-bios to say what should be available, or what build/test/run look like. Having a one-click button to profile and view the results in a graphical profile viewer would be amazing.

[alanz]

To me the server should be agnostic to the client, so these sorts of things should be provided via the standard protocol, in the first instance.

One way is to use a code lens, or code action.

Either of these would tie back to an execute command call, so if someone wanted to extend the client side to send the execute command based on some other UI affordance, they could do this, but as an extra enhancement, rather than being the only way to access it.

[jneira]

It seems that this could be a good application of the build-server-protocol. It aims to be a abstraction layer over build tools that can expose compile/run/test/repl actions to editors (see #9)

[alanz]

There is a thread about BSP in vscode, and the consensus seems to be that it is better as a backend to a LSP server, where we are using hie-bios instead.

See build-server-protocol/build-server-protocol#120 (comment)

[ndmitchell]

I guess I'd see haskell-language-server as predominantly a LSP backend plus plugins, but where features weren't available to be wired through LSP, having them custom for just a few plugins doesn't seem unreasonable. I think adding custom commands for build/test/run, and not necessarily having them wired through as code-lens (unless we can find a good place to put it) would still be valuable.

But it's quite possibly a different philosophy. Are we best IDE for N specific editors (my view), or best LSP for all editors.

[alanz]

But it's quite possibly a different philosophy. Are we best IDE for N specific editors (my view), or best LSP for all editors.

I think its possible to be both. If we follow the execute command approach for doing the actual work, then those can be implemented as custom commands in the client side.

But it leaves open the possibility of exposing them via code actions / code lenses too. If necessary turned off for VS Code, if they are directly provided via the plugin.

I am just worried about us starting on the path to being back in the bad old days of before LSP