[GH-ISSUE #66] [Enhancement] Add support for html message view keyboard shortcut

kerem commented

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

Owner

Originally created by @d99kris on GitHub (Jan 14, 2021).
Original GitHub issue: https://github.com/d99kris/nmail/issues/66

Originally assigned to: @d99kris on GitHub.

This is a feature request to add a keyboard shortcut to view the HTML version of an email message from message view as well as message list view.

A user-configurable command shall be used for opening the HTML message.

Originally created by @d99kris on GitHub (Jan 14, 2021). Original GitHub issue: https://github.com/d99kris/nmail/issues/66 Originally assigned to: @d99kris on GitHub. This is a feature request to add a keyboard shortcut to view the HTML version of an email message from message view as well as message list view. A user-configurable command shall be used for opening the HTML message.

kerem closed this issue

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

kerem commented

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

Author

Owner

@d99kris commented on GitHub (Jan 14, 2021):

This feature request is related to #42.

@d99kris commented on GitHub (Jan 14, 2021): This feature request is related to #42.

kerem commented

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

Author

Owner

@d99kris commented on GitHub (Jan 14, 2021):

This functionality has been implemented in above commit.

Note that the meaning of key_view_html in ui.conf has changed, it is from now on used to control the key binding used to view html from message list or message view. Previously it was used to control the key binding for viewing html preview while composing a message. The compose preview binding is now configured via key_preview_html in the same file.

Furthermore the default value for some settings have changed in the latest version. In order to use the new default values, one can simply delete ~/.nmail/ui.conf and start nmail. Alternatively, here is a list of parameters with new defaults (and their new default values):

    key_export=x
    key_external_pager=e
    key_view_html=v

@d99kris commented on GitHub (Jan 14, 2021): This functionality has been implemented in above commit. Note that the meaning of `key_view_html` in `ui.conf` has changed, it is from now on used to control the key binding used to view html from message list or message view. Previously it was used to control the key binding for viewing html preview while composing a message. The compose preview binding is now configured via `key_preview_html` in the same file. Furthermore the default value for some settings have changed in the latest version. In order to use the new default values, one can simply delete `~/.nmail/ui.conf` and start `nmail`. Alternatively, here is a list of parameters with new defaults (and their new default values): ``` key_export=x key_external_pager=e key_view_html=v ```

kerem commented

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

Author

Owner

@Kabouik commented on GitHub (Jan 14, 2021):

Looks cool! I'm toying around with browsh to see if I can get it to show the HTML message, but it's a bit circumvoluted because browsh can't display local files, they have to be served first.

caddy file-server ~/.nmail/nmail-account1/temp --listen :2015 & browsh http://localhost:2015/htmlview/1.html does not exactly work yet because the URL browsh opens with that is http://www.home.com/kabouik/.nmail/nmail-account1/temp/htmlview/1.html. From my tests with other browsers, I am assuming it is not possible to pass an URL in nmail's external command, as nmail already feeds the browser with /path/to/1.html automatically, and browsh needs the localhost URL.

I'm just playing with this concept that would mostly be useful when running nmail on a headless server anyway. On a local machine, I am not sure using browsh would be so useful since it takes a couple seconds to load anyway. It is usually faster to open the HTML in a new tab in Chrome/Firefox (Firefox is always open on my PC), without the downsides of a terminal browser.

htmlview/1.html (and possible inline attachments) is (are) created when hitting v, and removed when quitting the viewer, correct?

It's great to have this mechanism implemented. Hopefully I can understand the code in this commit and investigate how hard it would be for a noob like me to extend the feature to attachments.

@Kabouik commented on GitHub (Jan 14, 2021): Looks cool! I'm toying around with browsh to see if I can get it to show the HTML message, but it's a bit circumvoluted because browsh can't display local files, they have to be served first. `caddy file-server ~/.nmail/nmail-account1/temp --listen :2015 & browsh http://localhost:2015/htmlview/1.html` does not exactly work yet because the URL browsh opens with that is `http://www.home.com/kabouik/.nmail/nmail-account1/temp/htmlview/1.html`. From my tests with other browsers, I am assuming it is not possible to pass an URL in nmail's external command, as nmail already feeds the browser with `/path/to/1.html` automatically, and browsh needs the localhost URL. I'm just playing with this concept that would mostly be useful when running nmail on a headless server anyway. On a local machine, I am not sure using browsh would be so useful since it takes a couple seconds to load anyway. It is usually faster to open the HTML in a new tab in Chrome/Firefox (Firefox is always open on my PC), without the downsides of a terminal browser. `htmlview/1.html` (and possible inline attachments) is (are) created when hitting `v`, and removed when quitting the viewer, correct? It's great to have this mechanism implemented. Hopefully I can understand the code in this commit and investigate how hard it would be for a noob like me to extend the feature to attachments.

kerem commented

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

Author

Owner

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

htmlview/1.html (and possible inline attachments) is (are) created when hitting v, and removed when quitting the viewer, correct?

Kind of. Technically the temporary file is kept around until next message html view is requested, or nmail is exited. The reason for this is the asynchronous behavior of macOS open command.

@d99kris commented on GitHub (Jan 15, 2021): > htmlview/1.html (and possible inline attachments) is (are) created when hitting v, and removed when quitting the viewer, correct? Kind of. Technically the temporary file is kept around until next message html view is requested, or nmail is exited. The reason for this is the asynchronous behavior of macOS `open` command.

kerem commented

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

Author

Owner

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

It's great to have this mechanism implemented. Hopefully I can understand the code in this commit and investigate how hard it would be for a noob like me to extend the feature to attachments.

I wonder, would a command to access/open the entire email in an external viewer be useful for your use-case?

The entire email message in this case is an .eml file which can be unpacked using commands like munpack, etc.

I am still hesitant to more general customization, but just opening an email using an external command would be a reasonable feature I feel.

An .eml file contains the email message (html part, text part as well as any attachments).

@d99kris commented on GitHub (Jan 15, 2021): >It's great to have this mechanism implemented. Hopefully I can understand the code in this commit and investigate how hard it would be for a noob like me to extend the feature to attachments. I wonder, would a command to access/open the entire email in an external viewer be useful for your use-case? The entire email message in this case is an `.eml` file which can be unpacked using commands like `munpack`, etc. I am still hesitant to more general customization, but just opening an email using an external command would be a reasonable feature I feel. An `.eml` file contains the email message (html part, text part as well as any attachments).

kerem commented

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

Author

Owner

@Kabouik commented on GitHub (Jan 16, 2021):

I was not aware that .eml files contained attachments. This indeed looks like it could allow quite a lot of scripting to manipulate message body, headers and attachments if we can open the .eml with a custom command (for instance a script, not just a given viewer).

I'm not anywhere near having a single script ready for that, but that looks like a very nice playground. I assume it would be possible to export .eml parts to a temporary folder and have the script immediately run a CLI file manager inside the same terminal to browse that folder and offer extra actions. For instance, opening with nnn could look like that directly within the nmail terminal:

[1] [2] [3] [4] /path/to/tmp/extraction/dir/

file.hdr
file1.txt
file2.html
file3.pdf
file4.csv

nnn is a fast and frugal yet very extensible file manager thanks to many plugins and options, meaning it could offload a lot of flexibility while keeping nmail minimal. From there, actions and plugins in nnn could allow:

multiple selection to save several attachments at once into a single location (move/copy from extracted folder to new folder)
navigating through previously bookmarked locations for easy save locations
opening files with multiple GUI or CLI programs (the default is not always what one wants)
piping files into other scripts or programs (upload, print, copy to clipboard, rsync, grep, etc.)
batch-renaming
editing
opening in tiled, floating, or swallowing windows (see devour) and quitting nnn (hereby restoring nmail view)
archiving
and probably much more

Of course anyone could use their favourite CLI file manager if they have a use for such feature but prefer mc or ranger. One could also just use fzf and have an interactive prompt in their script with a set of predefined actions.

This is just a draft list of ideas for myself, hopefully I'm not missing something that would make any of this infeasible. But yes, if I am not missing something obvious, I think that would be pretty cool and useful, as well as a good balance to make nmail extensible using one's favourite tool without adding too much complexity to nmail itself.

@Kabouik commented on GitHub (Jan 16, 2021): I was not aware that .eml files contained attachments. This indeed looks like it could allow quite a lot of scripting to manipulate message body, headers and attachments if we can open the .eml with a custom command (for instance a script, not just a given viewer). I'm not anywhere near having a single script ready for that, but that looks like a very nice playground. I assume it would be possible to export .eml parts to a temporary folder and have the script immediately run a CLI file manager inside the same terminal to browse that folder and offer extra actions. For instance, opening with [`nnn`](https://github.com/jarun/nnn) could look like that directly within the `nmail` terminal: ``` [1] [2] [3] [4] /path/to/tmp/extraction/dir/ file.hdr file1.txt file2.html file3.pdf file4.csv ``` `nnn` is a fast and frugal yet very extensible file manager thanks to many plugins and options, meaning it could offload a lot of flexibility while keeping `nmail` minimal. From there, actions and plugins in `nnn` could allow: - multiple selection to save several attachments at once into a single location (move/copy from extracted folder to new folder) - navigating through previously bookmarked locations for easy save locations - opening files with multiple GUI or CLI programs (the default is not always what one wants) - piping files into other scripts or programs (upload, print, copy to clipboard, rsync, grep, etc.) - batch-renaming - editing - opening in tiled, floating, or swallowing windows (see [`devour`](https://github.com/salman-abedin/devour)) and quitting `nnn` (hereby restoring `nmail` view) - archiving - and probably much more Of course anyone could use their favourite CLI file manager if they have a use for such feature but prefer `mc` or `ranger`. One could also just use `fzf` and have an interactive prompt in their script with a set of predefined actions. This is just a draft list of ideas for myself, hopefully I'm not missing something that would make any of this infeasible. But yes, if I am not missing something obvious, I think that would be pretty cool and useful, as well as a good balance to make `nmail` extensible using one's favourite tool without adding too much complexity to `nmail` itself.

kerem commented

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

Author

Owner

@d99kris commented on GitHub (Jan 17, 2021):

Yeah I think those a great ideas that could be enabled. I've reported a new issue #68 to track adding this feature.

@d99kris commented on GitHub (Jan 17, 2021): Yeah I think those a great ideas that could be enabled. I've reported a new issue #68 to track adding this feature.

Rows
Columns

[GH-ISSUE #66] [Enhancement] Add support for html message view keyboard shortcut #59