[UX] keyboard shortcuts change suggestions

[adriangalilea]

Hello,

Very pleased with v1.0 thanks for your work @darrenburns,

(re: #23 (comment))

I would like to propose some UX changes/additions on shortcuts and navigation, most of them are minor and a matter of taste.

shift+enter send message when on input text mode

current: ctrl+j send message
I think it's fine to have a shortcut that sends the message without focus.

But it should also have shift+enter to send a message when focused in the input box. We all have muscle memory for this.

Why j tho? (I'm assuming not moving the finger from resting position? that's fair)

q exit mode

I would like to have exit mode just like lazygit, q, I understand this clashes with the focus mode that defaults to an input box, I would prefer to have q rather than defaulting to input text mode.

The focus could be on the pane and enter to actually input text, so now you can have q to exit without interfering with the text input.

navigation

default screen let's you press ↓ to change pane, but then you can not press ↑ to go back, this feels unnatural, so maybe, like lazygit again, you could ← → to navigate between panes, and ↓↑ to navigate between elements of a pane.

enter to select text mode

Keeping navigation consistent if the above suggestion sticks, I would do enter to select instead of space then:
esc to exit without copying.
space/enter to copy and exit the text selection mode

Also, I would like to have v helix style selection mode to avoid having to sustain shift depressed for the selection.

f1 f2 clashes with terminal shortcuts I have

Perhaps we can select on the config how some shortcuts behave, instead of trying to make some that try and fail to work for everyone.

I would prefer to have ? for help, this only works of course if you like the not defaulting to input text.

[darrenburns]

Thanks for your feedback!

I'm pretty sure shift+enter doesn't work on most terminals sadly.

For the exit stuff it's a bit of a trade-off: I think the most common user flow would be: open app, enter message. I'd like to keep the input focused by default to reduce that friction. escape key might work though.

Agree on the navigation. It just never made it into 1.0, but it will come.

The reason I didn't have enter for select mode was because previously this would open a "message details" panel. I think this suggestion makes sense though. Also the idea about presses esc to exit selection mode is needed - I actually keep pressing it myself!

I like the idea of toggle selection!

I'm not 100% sure how we'd have bindings pulled from config quite yet. Will need to do some research on the Textual side.

[adriangalilea]

I'm glad you liked the suggestions,

I'm pretty sure shift+enter doesn't work on most terminals sadly.

Oh, that's sad, it would be great to have it on for whatever terminals that do support it, my muscle memory seems to refuse ctrl+j :)

For the exit stuff it's a bit of a trade-off: I think the most common user flow would be: open app, enter message. I'd like to keep the input focused by default to reduce that friction. escape key might work though.

I totally understand this, and as you mentioned you could start with the input text by default but still have esc to exit input mode and have the focus on the pane, that way implementing q is feasible and it remains consistent with lazygit and some other TUI's I'm using(taskwarrior-tui for instance), it adds mental overhead to have several TUI's whose exit keybinding are different :)

I'm not 100% sure how we'd have bindings pulled from config quite yet. Will need to do some research on the Textual side.

Got it, I'm asking because I had F1 set up for kitty, and went ahead and changed it to F2 on kitty just to realise in the chat mode that F2 was also used 😆 so it may be convenient to others as well.

[darrenburns]

@adriangalilea Often you can remap keybindings at the terminal emulator level for more control. e.g. you could set shift+enter to send the same escape sequence as ctrl+j :)

Would you expect the q keybinding to work anywhere in Elia, as long as a text area isn't currently focused?

[adriangalilea]

@adriangalilea Often you can remap keybindings at the terminal emulator level for more control. e.g. you could set shift+enter to send the same escape sequence as ctrl+j :)

Will check thanks

Would you expect the q keybinding to work anywhere in Elia, as long as a text area isn't currently focused?

I see 2 options:

q exiting the program anywhere that's not inputting text.
esc working in "levels" pretty much as it does now but if you are on the initial position "Enter your message pane..." and the input text mode is already escaped the next esc quits the app. This way the flow is consistent and predictable.

Both of these are compatible, up to you ;)

[darrenburns]

@adriangalilea Some of the changes from this thread are now implemented and available in the latest version.

There's now visual select mode (press v - I still want to make the UI clearer for this though), the bindings are a little more intuitive (I think, but still got a little work to do on the up/down arrows), and you can press q to quit. esc now moves focus "closer to home", which is harder to explain precisely, but it feels better for me.

If you try it out, let me know how it goes!