-
Notifications
You must be signed in to change notification settings - Fork 88
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature request: support for compiling HLS from ghcup tui? #706
Comments
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:
Alternatively, a side pane menu could be possible. |
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. |
Hi! @david-christiansen feature discoverability is definitely an area we need to work on. As mentioned, not many people know about features like 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. |
@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 But maybe there's another reason why TUI for this might improve user experience? |
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 : -
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. |
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:
This logging could be enhanced to point to the documentation for HLS compilation: https://www.haskell.org/ghcup/guide/#hls |
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. |
but less click-baity.
I have a rough idea in mind.
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. |
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?
Add for other configure likes |
@July541 that sounds really hard and would require examining HLS cabal file. It seems overkill to me. |
A simple parser to extract |
I'm not very bullish about this. I think it's better to have good documentation about building HLS. |
@Ismor if you're interested in this, I'd be ok if someone gives it a shot. |
Sorry, @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? |
Popup logic in TUI that simulates the choices you have via cli. |
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? |
NB: I made an attempt to arrive at a spec which allows this feature request to be implemented. See my comment here: #949 (comment) |
This is now done, thanks to @lsmor |
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?The text was updated successfully, but these errors were encountered: