search

d99kris / nmail

Terminal-based email client for Linux and macOS
MIT License
136 stars 12 forks source link

[Enhancement] Show embedded pictures when viewing HTML message #41

Closed Kabouik closed 4 years ago

Kabouik commented 4 years ago

When viewed in an external application, HTML messages do not display attached pictures embedded in the text body, even if those images were individually viewed before. I think it is intentional. Yet, an option to show the HTML message including attached pictures would be nice, because some HTML emails (cancer emails :<) cannot be understood without viewing embedded pictures, and sometimes the image file names are not trivial enough to allow individually viewing the pictures in the right order.

Since showing attachments should not be enforced for security reasons, maybe add a new entry in the Message Parts view, in addition to text/html?

d99kris commented 4 years ago

It sounds like a reasonable functionality to support, given most email clients can display HTML messages with their embedded images. I'll look into this.

d99kris commented 4 years ago

This has been implemented now and is enabled by default. To disable this functionality edit ~/.nmail/ui.conf and set show_embedded_images=0.

Kabouik commented 4 years ago

Awesome, thanks.

Speaking of images embedded in the body of messages, they can now be viewed when opening the HTML version in a external browser, but what is your opinion on using Browsh as an alternative to Lynx to preview HTML in terminal?

This is more of an open question than a feature request, as it may be a lot of work and viewing images directly in the terminal thanks to Browsh kinda defeats the point of a terminal-based email client. I'm not asking for it, but I'm curious.

d99kris commented 4 years ago

It's a good question. Currently I feel incorporating browsh in nmail is too complex, especially to retain a consistent UI. I could imagine adding support for some keyboard shortcut to directly view the HTML message in an external program (which one can customize to be browsh), but not integrating browsh into the native message viewer.

Kabouik commented 4 years ago

Understood, I agree that keeping the UI consistent would be tricky. The idea of a keyboard shortcut is interesting.

I don't mean to distract you from the main focus of nmail, just discussing the idea:

  1. The shortcut could be used both from the message list and the message view.

  2. I believe it'd be nice if the associated command could be set in a new parameter instead of using ext_viewer_cmd=. Perhaps that's already what you were saying. That way, a user can keep the default xdg-open (or alternative) for all file associations in message parts, but use a custom command from the message list and message view. In the case of browsh, it could allow a lightweight text preview, just a little more feature rich than lynx [t] in nmail (which is really useful, by the way). For instance, custom_cmd_1=gnome-terminal -e 'browsh --startup-url $htmlmsg', provided such $variables are doable in nmail. Any other command could be imagined with different terminals or even something else to execute than browsh. Nothing comes to my mind just now, except maybe WM commands to open the new terminal at a specific window size, given coordinates, or floating vs. tiled for tiling WM, but I'm sure there would be more custom command possibilities.

Browsh doesn't seem to be opening very quickly, sadly.

d99kris commented 4 years ago

Browsh doesn't seem to be opening very quickly, sadly.

Yeah, I think it's a full-fledged browser (headless Firefox) behinds the scenes, so it's not very light-weight.

The shortcut could be used both from the message list and the message view.

Yes make sense.

I believe it'd be nice if the associated command could be set in a new parameter instead of using ext_viewer_cmd=.

Yes I think that's a valid point.

Feel free to submit a Github issue for adding this, although it might not be very high on my priority list at this point in time (there are other issues I'd like to address first).