[GH-ISSUE #42] [Enhancement] Keyboard shortcut to execute custom commands #42

Closed
opened 2026-03-03 01:19:18 +03:00 by kerem · 6 comments
Owner

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

Originally assigned to: @d99kris on GitHub.

As discussed in #41, it could be useful to allow using custom commands within nmail message list and message viewer. Ideally, the custom command would be set in a new parameter, instead of using ext_viewer_cmd=, so that the default file associations for message parts are conserved.

Custom commands could be used to open a message in a specific application for instance, like a text browser other than Lynx, like Browsh, for previewing those terrible HTML messages whose content is actually embedded in images. Could be useful on headless systems with no graphical interface for instance. Other possibilities include using tiling WM commands like i3's or alternatives', e.g., displaying the message in a given workspace, at given coordinates, in a given window geometry, and in floating or tiled window.

I don't know if variables can be extracted from nmail to distinguish text messages, html messages, image attachments, headers, etc., but if so, custom commands could get more powerful. For instance, custom_cmd_1=gnome-terminal -e 'browsh --startup-url $htmlmsg' would open the selected message in a new Gnome terminal and display it using Browsh, which could be combined with WM commands. If variables are not possible, I suppose applying the custom command to the target html message would be fine.

I don't know which other uses there could be to custom commands in a mail client, but since any bash script could be used as a command, I guess there would be many possibilities (?).

Originally created by @Kabouik on GitHub (May 16, 2020). Original GitHub issue: https://github.com/d99kris/nmail/issues/42 Originally assigned to: @d99kris on GitHub. As discussed in #41, it could be useful to allow using custom commands within `nmail` message list and message viewer. Ideally, the custom command would be set in a new parameter, instead of using `ext_viewer_cmd=`, so that the default file associations for message parts are conserved. Custom commands could be used to open a message in a specific application for instance, like a text browser other than Lynx, like Browsh, for previewing those terrible HTML messages whose content is actually embedded in images. Could be useful on headless systems with no graphical interface for instance. Other possibilities include using tiling WM commands like i3's or alternatives', _e.g._, displaying the message in a given workspace, at given coordinates, in a given window geometry, and in floating or tiled window. I don't know if variables can be extracted from `nmail` to distinguish text messages, html messages, image attachments, headers, _etc._, but if so, custom commands could get more powerful. For instance, `custom_cmd_1=gnome-terminal -e 'browsh --startup-url $htmlmsg'` would open the selected message in a new Gnome terminal and display it using Browsh, which could be combined with WM commands. If variables are not possible, I suppose applying the custom command to the target html message would be fine. I don't know which other uses there could be to custom commands in a mail client, but since any bash script could be used as a command, I guess there would be many possibilities (?).
kerem closed this issue 2026-03-03 01:19:18 +03:00
Author
Owner

@d99kris commented on GitHub (Jun 24, 2020):

Interesting idea. I assume the wish would be to add any number of custom commands. But no need to have these commands affect the email messages/folder, right? I.e. no general scripting control of nmail?

<!-- gh-comment-id:648897771 --> @d99kris commented on GitHub (Jun 24, 2020): Interesting idea. I assume the wish would be to add any number of custom commands. But no need to have these commands affect the email messages/folder, right? I.e. no general scripting control of nmail?
Author
Owner

@Kabouik commented on GitHub (Jul 7, 2020):

But no need to have these commands affect the email messages/folder, right? I.e. no general scripting control of nmail?

Right now I would have any use for that, no, but perhaps some users could see an opportunity to script automated tasks with nmail to move messages matching a pattern to a specific folder for instance? I think it would be perfectly fine to leave those "filter" tasks to the webmail and just keep nmail fetch remote folders once the sorting is done. Maybe there are other scripted actions that could be more relevant though? My own use case would probably only/mostly be with messages parts, or use external CLI tools to search strings through the cache.

<!-- gh-comment-id:654926730 --> @Kabouik commented on GitHub (Jul 7, 2020): > But no need to have these commands affect the email messages/folder, right? I.e. no general scripting control of nmail? Right now I would have any use for that, no, but perhaps some users could see an opportunity to script automated tasks with `nmail` to move messages matching a pattern to a specific folder for instance? I think it would be perfectly fine to leave those "filter" tasks to the webmail and just keep `nmail` fetch remote folders once the sorting is done. Maybe there are other scripted actions that could be more relevant though? My own use case would probably only/mostly be with messages parts, or use external CLI tools to search strings through the cache.
Author
Owner

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

Again, this is an interesting idea. It would make sense for a more extendable email client. But I've found myself short of time to just address the most critical issues and enhancements, so I will need to leave this out of scope for nmail and close this issue.

On a related note, I believe the terminal-based email client lumail https://lumail.org/ is highly customizable / scriptable, although I haven't tried it myself.

<!-- gh-comment-id:758647430 --> @d99kris commented on GitHub (Jan 12, 2021): Again, this is an interesting idea. It would make sense for a more extendable email client. But I've found myself short of time to just address the most critical issues and enhancements, so I will need to leave this out of scope for nmail and close this issue. On a related note, I believe the terminal-based email client lumail https://lumail.org/ is highly customizable / scriptable, although I haven't tried it myself.
Author
Owner

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

This one (and offline composing) is (are) a little bit more frustrating than the other rejected requests, but I totally understand your point. Better focus on most critical issues before extending nmail with advanced features that only few users would ever use (like the pipe feature described in this very issue).

I had already been considering lumail when moving from my previous email client, but I prefer nmail on many aspects (minimalistic yet featureful, UI, easy configuration, sane defaults, easily portable, etc.).

<!-- gh-comment-id:758674199 --> @Kabouik commented on GitHub (Jan 12, 2021): This one (and offline composing) is (are) a little bit more frustrating than the other rejected requests, but I totally understand your point. Better focus on most critical issues before extending nmail with advanced features that only few users would ever use (like the pipe feature described in this very issue). I had already been considering lumail when moving from my previous email client, but I prefer nmail on many aspects (minimalistic yet featureful, UI, easy configuration, sane defaults, easily portable, *etc.*).
Author
Owner

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

This one (and offline composing) is (are) a little bit more frustrating than the other rejected requests, but I totally understand your point. Better focus on most critical issues before extending nmail with advanced features that only few users would ever use (like the pipe feature described in this very issue).

Ok. To explain a bit further, my thinking is that it would be a significant amount of work (at least a few days) for a feature I expect a few number of users would use, and with my limited free time I don't think I can realistically address them. However, should someone propose a good design for this (and let me review) and then submit a pull request, I would probably be open to merging it. :-)

I'll keep your feedback in mind though, perhaps once I finish other requests and have free time I will have motivation to look into this request and others.

<!-- gh-comment-id:758714620 --> @d99kris commented on GitHub (Jan 12, 2021): > This one (and offline composing) is (are) a little bit more frustrating than the other rejected requests, but I totally understand your point. Better focus on most critical issues before extending nmail with advanced features that only few users would ever use (like the pipe feature described in this very issue). Ok. To explain a bit further, my thinking is that it would be a significant amount of work (at least a few days) for a feature I expect a few number of users would use, and with my limited free time I don't think I can realistically address them. _However_, should someone propose a good design for this (and let me review) and then submit a pull request, I would _probably_ be open to merging it. :-) I'll keep your feedback in mind though, perhaps once I finish other requests and have free time I will have motivation to look into this request and others.
Author
Owner

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

The custom html view keyboard shortcut support has been implemented now.

Not sure to which extent addresses the pain point, but hopefully it's of some use.

<!-- gh-comment-id:760165141 --> @d99kris commented on GitHub (Jan 14, 2021): The custom html view keyboard shortcut support has been implemented now. Not sure to which extent addresses the pain point, but hopefully it's of some use.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/nmail#42
No description provided.