Could aerc parse messages recursively? I have a message which has few message/rfc822 attachments, and some of these have their own binary attachments (Word documents), all sent by Thunderbird. It doesn't seem to work by default.
I wrote caeml a while back for filtering
message/rfc822, which could be definitely improved a bit (other than the already open tickets). On the other hand I think the canonical solution for this is calling:emlon it and loading the message completely in aerc. Are you suggesting that aerc should just unpack message/rfc822 attachments recursively in the mime selector?
On Thu Feb 1, 2024 at 7:12 AM CET, ~ferdinandyb wrote:
I wrote caeml a while back for filtering
message/rfc822, which could be definitely improved a bit (other than the already open tickets). On the other hand I think the canonical solution for this is calling:emlon it and loading the message completely in aerc. Are you suggesting that aerc should just unpack message/rfc822 attachments recursively in the mime selector?Let me parse the previous message into three possible solutions:
- Right now, it is possible to use caeml (or any other similar utility, isn’t this what metamail used to do?) as a simple filter to display some significant information about the attached messages in plain text and thus in the aerc message window.
- When browsing through the message in the message reader tab with Ctrl-J/K and hitting message/rfc822 attachment, a new tab would open with the embedded message, which would behave as any other message tab, i.e., that message could be read, replied to, forwarded, and its attachments could be browsed through. That’s exactly what Thunderbird does (of course, modulo difference between GUI and TUI nature of two apps).
- When opening a message with attached message/rfc822 attachments, aerc would go recursively through the message and display somehow recursively the whole structure of the message and all its embedded messages.
Is that correct?
What I meant was firmly the option #2.
-- http://matej.ceplovi.cz/blog/, @mcepl@floss.social GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8
Thou shalt not nede to be afrayed for any bugges by night. -- Coverdale’s 1535 translation of Psalm 91 (or Christopher Higley’s 1972 thesis explaining why programmers’ are nocturnal beasts)
Number 2 partially works now, you can call
:eml/:previewon a message/rfc822 attachment, but you can't reply to it currently, for that I opened another ticket. For reading it should already work as you'd like to.On the other hand, I think it would be cool if you could have an option/command that recursively unfolds all message/rfc822 attachments in the currently viewed email. This would allow to read a digest with all attachments and everything quite easily. Calling :eml on the message/rfc822 part would still open it properly as an individual email for replying, etc.
Number 2 partially works now, you can call
:eml/:previewon a message/rfc822 attachment, but you can't reply to it currently, for that I opened another ticket. For reading it should already work as you'd like to.Oh, that’s great! Yes, it works more or less like expected it to, just without the active part. I am wondering about the UI though.
I have originally thought that new tab would open without any other intervention, when the cursor just gets to it (with Ctrl-J/K), but that’s probably too much random action for anybody’s comfort.
I can bind a new key to it, of course, but when I was looking at it, I saw a completely useless (for message/rfc822)
Obinding for:opencommand. Couldn’t it and:eml/:previewbe somehow unified? Or at least to make an alternate binding (do:emlfor email message,:openotherwise)?On the other hand, I think it would be cool if you could have an option/command that recursively unfolds all message/rfc822 attachments in the currently viewed email. This would allow to read a digest with all attachments and everything quite easily. Calling :eml on the message/rfc822 part would still open it properly as an individual email for replying, etc.
It could be useful, and it should be probably available somehow, but (especially considering how complicated and deep structure of MIME messages could be) I don’t think I would like it as a default or only behaviour. That seems like Too Much Information™. Just a list of titles (with indication of MIME type) is probably enough, more or less what we have now.
Don't you already see a suggestion to open the rfc822 message with :eml. I get this option list on master for message/rfc822 attachments:
O Open using the system handler :open<enter> S Save to file :save<space> | Pipe to shell command :pipe<space> m View message attachment :eml<Enter>So you should be able to just press
mto view the attached message in a new message viewer tab?
On Fri Feb 2, 2024 at 11:02 AM CET, ~konimarti wrote:
Don't you already see a suggestion to open the rfc822 message with :eml. I get this option list on master for message/rfc822 attachments:
- I don’t have
mthere, but that could be probably easily fixed in the configuration.- I have started to play with Bence’s https://github.com/ferdinandyb/caeml and it looks pretty reasonable. Unfortunately, when replying to the shown message I get raw unencoded message to reply to, which is a little bit less useful.
On Fri Feb 2, 2024 at 11:41 AM CET, ~mcepl wrote:
- I don’t have
mthere, but that could be probably easily fixed in the configuration.Apologies, you're right.
mis not in the default binds.conf. You just see the line without themkey. I havem = :eml<Enter>in the [view] section of my binds.conf.
On Fri Feb 02, 2024 at 11:41, ~mcepl outgoing@sr.ht wrote:
On Fri Feb 2, 2024 at 11:02 AM CET, ~konimarti wrote:
Don't you already see a suggestion to open the rfc822 message with :eml. I get this option list on master for message/rfc822 attachments:
- I don’t have
mthere, but that could be probably easily fixed in the configuration.- I have started to play with Bence’s https://github.com/ferdinandyb/caeml and it looks pretty reasonable. Unfortunately, when replying to the shown message I get raw unencoded message to reply to, which is a little bit less useful.
I wonder why that happens? Oh right, if you reply to a picture attachment you would also get the raw image. This is a general property with parts. I guess you can use caeml to view and if you do want to reply, :eml (after Koni's new patch is applied).