[GH-ISSUE #78] [Enhancement] Distinct keybindings for reply-to and reply-to-all

kerem commented

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

Owner

Originally created by @Kabouik on GitHub (May 8, 2021).
Original GitHub issue: https://github.com/d99kris/nmail/issues/78

Originally assigned to: @d99kris on GitHub.

I haven't often needed it, as the default behaviour can easily be turned into a reply-to with ^K in the CC field, but not everyone knows about this keybinding and many users usually expect to have two different buttons for reply-to and reply-to-all in their GUI client.

I also encountered some cases in nmail where the received email was sent in such a way that all co-recipients were not automatically included in CC with the current implementation, and this is where I lacked a forced reply-to-all.

Something like r and R as default would work for instance, but the nmail help bar currently only shows upper case keys.

Originally created by @Kabouik on GitHub (May 8, 2021). Original GitHub issue: https://github.com/d99kris/nmail/issues/78 Originally assigned to: @d99kris on GitHub. I haven't often needed it, as the default behaviour can easily be turned into a reply-to with `^K` in the CC field, but not everyone knows about this keybinding and many users usually expect to have two different buttons for reply-to and reply-to-all in their GUI client. I also encountered some cases in nmail where the received email was sent in such a way that all co-recipients were not automatically included in CC with the current implementation, and this is where I lacked a forced reply-to-all. Something like `r` and `R` as default would work for instance, but the nmail help bar currently only shows upper case keys.

kerem closed this issue

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

kerem commented

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

Author

Owner

@d99kris commented on GitHub (May 15, 2021):

Support for reply to sender was added in above commit. Default key bindings:
r - reply all (like before)
R - reply to sender (new command)

For now there will be no UI help bar indication for "reply to sender" (for the reason you mentioned). I have tested a couple of options:

Showing lower-case r and upper-case R
Prefixing shifted keys, e.g. ⇧R, ↑R or ⇫R.

But unfortunately neither looks that great in my opinion and for option 2 there's also the issue that not all terminal/fonts can display these characters, so for now I just left that one out. In the future I may need to revisit this and figure out a good indication for shifted (vs. regular) keys.

@d99kris commented on GitHub (May 15, 2021): Support for reply to sender was added in above commit. Default key bindings: `r` - reply all (like before) `R` - reply to sender (new command) For now there will be no UI help bar indication for "reply to sender" (for the reason you mentioned). I have tested a couple of options: 1. Showing lower-case `r` and upper-case `R` 2. Prefixing shifted keys, e.g. `⇧R`, `↑R` or `⇫R`. But unfortunately neither looks that great in my opinion and for option 2 there's also the issue that not all terminal/fonts can display these characters, so for now I just left that one out. In the future I may need to revisit this and figure out a good indication for shifted (vs. regular) keys.

kerem commented

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

Author

Owner

@Kabouik commented on GitHub (May 17, 2021):

Nice, thanks!

Yes I agree the aesthetics implications of this make a difficult question. I believe discriminating upper case and lower case in
keybindings will be very useful though. It's already hard enough to combine keybindings of a tiling WM + a featureful terminal emulator (like kitty or tilix for instance) + readline keybindings + nmail keybindings. I realized recently how difficult it was to find just one "free" keybinding to replace ^T in nmail because I started using in Kitty for new tabs. Adding Shift in the balance will help, but will require some visual feedback if many keys start using it.

Without seeing it in action, I would say I would probably prefer the more minimal way with just r/R, I'm afraid a symbol for Shift would clutter the view, or cause alignment issues. But maybe other possibilities could be explored, like 'r'reply all/'R'eply', or [r]eply all/[R]eply, or inverted fg/bg for the keybind character. Just listing ideas, I'm not even sure myself yet what I would prefer.

@Kabouik commented on GitHub (May 17, 2021): Nice, thanks! Yes I agree the aesthetics implications of this make a difficult question. I believe discriminating upper case and lower case in keybindings will be very useful though. It's already hard enough to combine keybindings of a tiling WM + a featureful terminal emulator (like kitty or tilix for instance) + readline keybindings + nmail keybindings. I realized recently how difficult it was to find just one "free" keybinding to replace <kbd>^T</kbd> in nmail because I started using in Kitty for new tabs. Adding <kbd>Shift</kbd> in the balance will help, but will require some visual feedback if many keys start using it. Without seeing it in action, I would say I would probably prefer the more minimal way with just <kbd>r</kbd>/<kbd>R</kbd>, I'm afraid a symbol for <kbd>Shift</kbd> would clutter the view, or cause alignment issues. But maybe other possibilities could be explored, like `'r'reply all`/`'R'eply'`, or `[r]eply all`/`[R]eply`, or inverted fg/bg for the keybind character. Just listing ideas, I'm not even sure myself yet what I would prefer.

kerem commented

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

Author

Owner

@Kabouik commented on GitHub (May 17, 2021):

Also what could help could be a additional function to toggle the help bar on and off. It is already a configuration option, but has to be set in advance. With a toggle key like ? (already in use for the search function, I know, but it's not an usual key for that), users could declutter the view most of the time and show the keybindings just when needed. Using ? for that is classic in many TUIs (where they usually show a full help screen, but just overlaying the help bar would be enough here). One issue is it would not work in the compose view, so that's not a mature idea yet.

@Kabouik commented on GitHub (May 17, 2021): Also what could help could be a additional function to toggle the help bar on and off. It is already a configuration option, but has to be set in advance. With a toggle key like <kbd>?</kbd> (already in use for the search function, I know, but it's not an usual key for that), users could declutter the view most of the time and show the keybindings just when needed. Using <kbd>?</kbd> for that is classic in many TUIs (where they usually show a full help screen, but just overlaying the help bar would be enough here). One issue is it would not work in the compose view, so that's not a mature idea yet.

kerem commented

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

Author

Owner

@d99kris commented on GitHub (May 18, 2021):

Thanks for the input on lower-case keybindings, I'll keep it in mind and revisit eventually.

With respect to enabling/disabling help bar in run-time, feel free to submit an issue - it should be fairly simple to implement I think. But yeah, the default keybinding may need some consideration.

For some of the commands that today is available in compose and other views, a regular letter is used (with CTRL modifier in compose-mode), for example V / ^V for opening external html viewer. So we could consider something similar for toggling helpbar.

On 2021-05-17 21:34 Kabouik @.***> wrote:

Also what could help could be a additional function to toggle the
help bar on and off. It is already a configuration option, but has to
be set in advance. With a toggle key like ? (already in
use for the search function, I know, but it's not an usual key for
that), users could declutter the view most of the time and show the
keybindings just when needed. Using ? for that is classic
in many TUIs (where they usually show a full help screen, but just
overlaying the help bar would be enough here).

--
You are receiving this because you modified the open/close state.
Reply to this email directly or view it on GitHub:
https://github.com/d99kris/nmail/issues/78#issuecomment-842329248

@d99kris commented on GitHub (May 18, 2021): Thanks for the input on lower-case keybindings, I'll keep it in mind and revisit eventually. With respect to enabling/disabling help bar in run-time, feel free to submit an issue - it should be fairly simple to implement I think. But yeah, the default keybinding may need some consideration. For some of the commands that today is available in compose and other views, a regular letter is used (with `CTRL` modifier in compose-mode), for example `V` / `^V` for opening external html viewer. So we could consider something similar for toggling helpbar. On 2021-05-17 21:34 Kabouik ***@***.***> wrote: > Also what could help could be a additional function to toggle the > help bar on and off. It is already a configuration option, but has to > be set in advance. With a toggle key like <kbd>?</kbd> (already in > use for the search function, I know, but it's not an usual key for > that), users could declutter the view most of the time and show the > keybindings just when needed. Using <kbd>?</kbd> for that is classic > in many TUIs (where they usually show a full help screen, but just > overlaying the help bar would be enough here). > > -- > You are receiving this because you modified the open/close state. > Reply to this email directly or view it on GitHub: > https://github.com/d99kris/nmail/issues/78#issuecomment-842329248

Rows
Columns

[GH-ISSUE #78] [Enhancement] Distinct keybindings for reply-to and reply-to-all #68