[GH-ISSUE #43] [Bug] Wrong keybinding label in the help bar for KEY_LEFT and KEY_RIGHT #40

New issue

Closed

opened 2026-03-03 01:19:18 +03:00 by kerem · 4 comments

kerem commented

2026-03-03 01:19:18 +03:00

Owner

Originally created by @Kabouik on GitHub (May 25, 2020).
Original GitHub issue: https://github.com/d99kris/nmail/issues/43

Originally assigned to: @d99kris on GitHub.

When changing the keys for key_open and key_back to KEY_RIGHT and KEY_LEFT, the bottom help bar shows ^E and ^D respectively instead of the actual new keybindings.

Originally created by @Kabouik on GitHub (May 25, 2020). Original GitHub issue: https://github.com/d99kris/nmail/issues/43 Originally assigned to: @d99kris on GitHub. When changing the keys for `key_open` and `key_back` to `KEY_RIGHT` and `KEY_LEFT`, the bottom help bar shows `^E` and `^D` respectively instead of the actual new keybindings.

kerem closed this issue

2026-03-03 01:19:18 +03:00

kerem commented

2026-03-03 01:19:19 +03:00

Author

Owner

@d99kris commented on GitHub (May 25, 2020):

Yes, nmail is currently missing mapping of some non-printable keyboard shortcuts to proper names.

For keypad arrows we can perhaps use: ← → ↑ ↓

Function keys can be: F1-F9 (+ 10-19?)

Need to think about suitable names / symbols for others, like:
tab, space, enter, delete, home, end, page up/down, clear, escape.

@d99kris commented on GitHub (May 25, 2020): Yes, nmail is currently missing mapping of some non-printable keyboard shortcuts to proper names. For keypad arrows we can perhaps use: ← → ↑ ↓ Function keys can be: F1-F9 (+ 10-19?) Need to think about suitable names / symbols for others, like: tab, space, enter, delete, home, end, page up/down, clear, escape.

kerem commented

2026-03-03 01:19:19 +03:00

Author

Owner

@Kabouik commented on GitHub (May 26, 2020):

How many characters would you allow in keybinding labels at maximum?

I think the following names/abbreviations are standard, or at least straightforward enough to be understood, but some may be a tad long for a help bar: Tab, Space, Enter, Del, Home, End, PgUp, PgDn, Esc

@Kabouik commented on GitHub (May 26, 2020): How many characters would you allow in keybinding labels at maximum? I think the following names/abbreviations are standard, or at least straightforward enough to be understood, but some may be a tad long for a help bar: `Tab`, `Space`, `Enter`, `Del`, `Home`, `End`, `PgUp`, `PgDn`, `Esc`

kerem commented

2026-03-03 01:19:19 +03:00

Author

Owner

@d99kris commented on GitHub (May 30, 2020):

TLDR: I'll fix the bug for KEY_LEFT and KEY_RIGHT first, and remaining issues under #9.

I forgot to mention, but this is an interesting issue. Originally I wanted to follow the pine/alpine UI, which allows both </> and ←/→ to navigate between the screens (the helpbar only shows </> though). But when #9 was reported I realized I had missed it out, and was hesitant to add the mapping unless it could be configured. And my current design only allows one key user-configured per function, so it got put on hold for a while. Anyway, that's a side-note. And I am planning to address this as part of #9 eventually.

To not get stuck on this issue for too long I am planning to just implement a fix for the problem (key left/right). I will address other keys as part of #9 - unless there's some request coming in before that.

Regarding your question:

How many characters would you allow in keybinding labels at maximum?

I would prefer 1-2 characters - the UI looks more balanced when the keybinding labels are of similar length. But.. As long as the default UI looks fine, it's not the end of the world to allow longer labels for "uncommon" configs.

I think the following names/abbreviations are standard

Thanks for the suggestions, they look pretty good to me!

One thing to note though - for several of these keys, they are already assigned an implicit non-configurable function (at this point... after #9 this will probably change), like Space, Enter, Del, Home, End, PgUp, PgDn. And these keys are currently not shown in the helpbar (as they follow fairly common UI behavior).

@d99kris commented on GitHub (May 30, 2020): **TLDR**: I'll fix the bug for KEY_LEFT and KEY_RIGHT first, and remaining issues under #9. I forgot to mention, but this is an interesting issue. Originally I wanted to follow the `pine`/`alpine` UI, which allows both `<`/`>` and `←`/`→` to navigate between the screens (the helpbar only shows `<`/`>` though). But when #9 was reported I realized I had missed it out, and was hesitant to add the mapping unless it could be configured. And my current design only allows one key user-configured per function, so it got put on hold for a while. _Anyway_, that's a side-note. And I am planning to address this as part of #9 eventually. To not get stuck on this issue for too long I am planning to just implement a fix for the problem (key left/right). I will address other keys as part of #9 - unless there's some request coming in before that. Regarding your question: > How many characters would you allow in keybinding labels at maximum? I would prefer 1-2 characters - the UI looks more balanced when the keybinding labels are of similar length. But.. As long as the default UI looks fine, it's not the end of the world to allow longer labels for "uncommon" configs. > I think the following names/abbreviations are standard Thanks for the suggestions, they look pretty good to me! One thing to note though - for several of these keys, they are already assigned an implicit non-configurable function (at this point... after #9 this will probably change), like `Space`, `Enter`, `Del`, `Home`, `End`, `PgUp`, `PgDn`. And these keys are currently not shown in the helpbar (as they follow fairly common UI behavior).

kerem commented

2026-03-03 01:19:19 +03:00

Author

Owner

@Kabouik commented on GitHub (May 30, 2020):

Interesting, thanks for the clarification.

@Kabouik commented on GitHub (May 30, 2020): Interesting, thanks for the clarification.