Open romanofski opened 4 years ago
So let's keep it simple to begin with: a list (or list-like structure) of inline entities (pre-processed; ready for presentation). Use the mailcap data to grub out entities for inline display (but at most one branch of a multipart/alternative
message).
So, things to skip for the initial cut: folding, deferred processing.
Is your feature request related to a problem? Please describe. Attachments which can be handled in the terminal should be showed directly in the mail view body. At this point in time the AST can not represent any attachments.
For example, if I want to see the textual output of an MS word document and register either pandoc or antiword as a handler, I
a) still need to actually navigate and open the attachment and b) since it's not piped through a pager I can only see as much as my terminal is high.
Describe the solution you'd like I think we should also show attachments in the mailview. Perhaps keep them folded by default to avoid always piping and parsing the entire mail with it's sometimes gigantic attachments. On request we can unfold the attachments so it's an easy keypress to see all.
Describe alternatives you've considered Alternatively - perhaps in a separate card - either support piping through a pager, or better: show the output of the command in a viewport (see
UI.Help.Main.hs
as an example).Additional context None