search

haskell / haskell-language-server

Official haskell ide support via language server (LSP). Successor of ghcide & haskell-ide-engine.
Apache License 2.0
2.71k stars 368 forks source link

Add actions to control the build tool throug hls #113

Open juergenpf opened 4 years ago

juergenpf commented 4 years ago

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

Haskelly

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 https://github.com/build-server-protocol/build-server-protocol/issues/120#issuecomment-636533229

ndmitchell commented 4 years ago

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 commented 4 years ago

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