Feature request: support for compiling HLS from ghcup tui?

[david-christiansen]

The ability of GHCup to compile HLS from source for a given HLS and compiler version is an under-appreciated, valuable feature. I think that many users aren't aware of how easy this actually is.

Would it be feasible to add some kind of indication to ghcup tui that a given GHC that doesn't have an HLS binary can be used to attempt to compile it?

[hasufell]

Feature wise this makes sense. It's just that it's not trivial to design. We already have a lot of hotkeys, so I don't want to overload it with more. This would mean to implement some type of menu or navigation.

So maybe:

• default is still opening the tools page
• we add one more hotkey m for opening the menu
• the menu will be a new page with 2 items 'tool bindists' and 'compile HLS'
• a command line option can be passed to ghcup tui to open a different page by default
• maybe this requires a more concise presentation of the hotkeys... only the most important should be shown by default and ? should open a help page

Alternatively, a side pane menu could be possible.

[david-christiansen]

What about a system where installing a version of GHC that doesn't have a pre-compiled HLS prompts the user as to whether they want to build it themselves? It'd be annoying to accidentally say "no" and then have to go look up the syntax for the command line to do so, but then people would know that it's a reasonable thing to do and that they should look for it.

[arjunkathuria]

Hi! @david-christiansen feature discoverability is definitely an area we need to work on. As mentioned, not many people know about features like ghcup compile or other useful features like isolated installs, which i would term as somewhat advanced features (i.e. not needed by most users in most cases, but pretty handy in their use-cases).

I don't think nested menus via a TUI is an optimal way to go here, we should keep the TUI simple.

I Think better upfront documentation, with a dedicated advanced section (something similar to what stack does with it's docs), would be more effective.

We can also think about adding prompts with helpful suggestions and hints where possible without them becoming tedious, overbearing or annoying, while keeping the quick "come, install, exit" feel of the tool at the center of user experience.

[hasufell]

@arjunkathuria that's an interesting stance.

I think it's true some of the success of GHCup might be due to the simplicity and that the tool gets out of your way.

So what is really the value of the TUI? Yeah, I think it's mostly a better presentation of the list of available and installed tools. So it's about concise information that can be easily navigated. Maybe it's much less about the "interactivity" of installation. Then the question would be what is the value of doing compilation in the TUI when it doesn't add to the value of information presentation? Filling in boxes and inputs instead of typing it in the cli?

I also have to note that GHCup has quite sophisticated shell completion, e.g. it will complete available HLS versions and all sorts of other things when you do ghcup compile hls....

But maybe there's another reason why TUI for this might improve user experience?

[arjunkathuria]

I'd also like to mention that the current TUI doesn't support (or even mention) the above mentioned advanced methods of installation & operation.

When i want to install a tool, say GHC, currently : -

• It doesn't have the option to indicate or ask me if it's an isolated install (as opposed to a regular install)
• It doesn't have the option to indicate or ask me if it's an force install
• it doesn't have the option to indicate or ask me if I'd like to compile it instead of downloading a bin-dist

which further adds to the invisibility of those features.

Keeping TUI in a 1:1 feature parity with the command line options and flags is also another way where we can highlight their existence and then convey the fact that they can help in certain / advanced situations, where the default behavior is undesired or unsupported.

[hasufell]

Keeping TUI in a 1:1 feature parity with the command line options and flags is also another way where we can highlight their existence

I'm not sure how, though. Opening a new dialog popup? A side pane with options? I feel presenting optional command line options in a GUI is always somewhat clunky. Asking a bazillion interactive questions also won't be a better user experience.

I'm in fact leaning more towards keeping only very basic installation features in the TUI. So a compilation for HLS should pick the most reasonable defaults and not overwhelm the user with options. A hotkey for installation could show up if you select a GHC version that isn't hls-powered yet, maybe.

Otherwise, we're already printing a warning, when you install HLS or set a new GHC version, like so:

[ Warn  ] GHC 9.4.3 is not compatible with Haskell Language Server 1.8.0.0-72-g5a8ccdbe.
[ ...   ] Haskell IDE support may not work until this is fixed.
[ ...   ] Install a different HLS version, or install and set one of the following GHCs:
[ ...   ] [9.2.5]

This logging could be enhanced to point to the documentation for HLS compilation: https://www.haskell.org/ghcup/guide/#hls

[Kleidukos]

Truly good things will arise from thinking (and prototyping) with ways to improve discoverability within the TUI.

I feel like this should be an R&D project that would need an investment of time and resources separate from the ghcup usual release cycle.

Reading the comments I feel like @arjunkathuria has some ideas that could certainly bear interesting fruits. I would encourage him to invest proper time in UI design.

I don't have a better suggestion than @hasufell's regarding what could be a "quick win" in terms of directions for the user.

[arjunkathuria]

@hasufell

1. Letting users know in a warning for now is a nice & easy win, we can add a helpful hint here, something like :

[ Warn  ] GHC 9.4.3 is not compatible with Haskell Language Server 1.8.0.0-72-g5a8ccdbe.
[ ...   ] Haskell IDE support may not work until this is fixed.
[ ...   ] Install a different HLS version, or install and set one of the following GHCs:
[ ...   ] [9.2.5]
[ ...   ] 
[ ...   ] Meanwhile, You can compile HLS yourself pretty easily, to get you up and working 
[ ...   ] until the official HLS releases are out
[ ...   ] with this one simple trick!
[ ...   ] $ ghcup compile hls -g master --ghc 9.2.5

but less click-baity.

I'm not sure how, though.

@hasufell @Kleidukos

I have a rough idea in mind.

• Each ghcup command corresponding to level 1 ghcup function is bound to a key in the main TUI screen
  So things that are top level ghcup commands like install, set, uninstall, compile etc are the only things that get their own keys.

• When you select a command, say you selected to install ghc version 9.2.5, instead of straight away installing it, it'll popup a smallish pop-up, divided in two sections - basic install and advanced options -, The pop-up would need to be over the main screen so it doesn't cause user disorientation, or make the users think its a complicated new screen.

• The current default behavior is the only thing listed in the basic section and is pre-selected. The user just needs to press enter one more time if they just want a quick install and not bother with the advanced options.

• The Advanced section has a bunch of switches that correspond to the flags the top level command selected supports, which in this case make the pop-up look something like : -

Basic installation (this is what most users want 99% of the time)

  - regular install (this is pre-selected and highlighted)

Advanced Options
  ( - i ) isolated install : <description of an isolated install>
  ( - f ) force install : < description of a forced install > 
  ( -o ) some other flag that install command supports

The advanced options are multi-select here, you can select one or more of them at once. (say you want a forced isolated install, just press /select -f and -i )

If it's something that needs user input, like a path in case of an isolated install, it happens on the bottom of the same popup, again, to prevent user disorientation.

All of this is very rough and mostly based on the Magit interface i use daily in emacs. It works for me brilliantly.

[July541]

I prefer it is designed for advanced users, not for experts.

Can some checkboxes be given in tui to let the user specify these details?

# Plugins
- [ ] hls-xxx-plugin
- [ ] hls-xxx-plugin
# GHCs
- [ ] 9.2
- [ ] 9.4
- [ ] 9.6

Add for other configure likes git-ref, isolate, anything that needs to type should be passed from the command.

[hasufell]

@July541 that sounds really hard and would require examining HLS cabal file. It seems overkill to me.

[July541]

A simple parser to extract flag and tested-with, and plus tacit understanding between ghcup and hls(hls should keep these fields updated), enough?

[hasufell]

I'm not very bullish about this. I think it's better to have good documentation about building HLS.

[hasufell]

@Ismor if you're interested in this, I'd be ok if someone gives it a shot.

[hasufell]

Sorry, @lsmor

[lsmor]

I could give it a try. Just to be clear, the Idea is to implement the pop-up logic in the comment by @arjunkathuria or to create an information page about?

[hasufell]

I could give it a try. Just to be clear, the Idea is to implement the pop-up logic in the comment by @arjunkathuria or to create an information page about?

Popup logic in TUI that simulates the choices you have via cli.

[lsmor]

ping: @arjunkathuria and @hasufell

I have this prototype. The logic of the widget is mostly implemented (moving around, writing , check box, etc...). The instalation logic is missing. That is, at the time of writing this No instalation is done. I'll ask for help later because I am not very sure how to do it. In the mean time, may I have some feedback about the visuals?

[runeksvendsen]

NB: I made an attempt to arrive at a spec which allows this feature request to be implemented. See my comment here: #949 (comment)