idursun
FR: Wrap help footer on several lines
Is your feature request related to a problem? Please describe.
In a small terminal windows, the help footer overflows quite a lot on the right. This happens a lot when I use jjui in a terminal split or a tmux pane.
Describe the solution you'd like
The default footer could be shorter, wrapped on several lines, to be visible on small windows. Best case, it is reactive to the terminal window width.
Describe alternatives you've considered
I resize my pane/window by hand after opening jjui. It's okay.
Why current features fail to cover this request
Opening the help modal with ? helps a bit, but it is a big modal and is non-reactive.
So it is equally clipped in narrow terminal surfaces.
Additional context
Hey, thanks!
Best case, it is reactive to the terminal window width.
It gets cut off the on the right side of the terminal. Be being "reactive" do you mean it should change the contents of the help depending on the available width? or do you mean that it doesn't redraw when the pane is resized?
I tried it in tmux and it resized ok for me. Obviously the contents of the status bar is cut off.
The default footer could be shorter, wrapped on several lines
I have tried wrapping it in the past and it looks awful (almost looks like broken).
I can work on the help window though, it's very crowded at the moment. My plan is to replace it with a command palette later on.
hey @idursun @lvignoli i tried some experiments, this is the best i could get right now
- footer is reactive to window width, adjusting window size updates footer width in real time
- if the new height is multiples of 2 (see below screenshot when it's 2 rows),
modewill be added, otherwise if it's justnormal, the text not being vertically centered looks hella weird - if the new height is not multiples of 2, the text is vertically centered
if you guys think this ui looks good i'll open a PR (not sure if idursun has any plans on changing up the footer completely)
Hey @baggiiiie Thanks for looking into this.
I had done the same in the past and I still think it looks broken. I think a better approach for going forward is to not show the shortcuts in the status bar at all. I am thinking of showing one thing there which ? and the help would show only the relevant shortcuts over there (or would appear at the bottom of the status to show the shortcuts like you have done here).
This issue will be solved in one way or the other but will take some redesign.
@idursun yup i agree, another thing im experimenting is something like below (from the editor helix). is this something resembling what you meant by whichkey? like neovim which key?
One thing I do Love about Emacs transient menus -- I used magit for years before using jjui -- is that you can not only select actions to run, but you can also toggle flags (like our --ignore-immutable or --at-operation <OP>), it feels like composing a command line interactively before invoking the action.
In emacs the transient menu grows upwards as more options are enabled, but it depends on the number of flags/sub-commands the current key-map has (it also has pagination and search from inside the transient menu, I believe vim/helix also do things like this)
@vic that's neat!
I had done something similar in one of those hundred branches that I lost the track of now.
My approach was to show a command preview in the status bar along with the possible arguments that can be activated, which looked good but UI didn't look good. However, that implementation dedicated the status bar only to the command previews and removed the list of shortcuts (only showed ? to list them all)
This is still a solid option going forward as it shows the command to be executed and gives an intuitive way to tweak it. I need to get back to it to see potential upsides and downsides.