From my side, it looks like so. Thank you very much :)

Not only in the attachment filename but also in the Subject (and other fields may be affected, too).

A short follow up to my previous comment: if I move that letter with an inserted linebreak in a Subject to an empty folder, so that it would the only letter there, then aerc will display it like this, showing exactly that added/inserted symbol as indeed a linebreak.

Can confirm: tried to send an attachment named with Cyrillic characters, лето лето.png (note the absence of any leading spaces or whatever). Got the same error while sending, imap: size of Literal is not equal to Len() (428883 != 428884). And the received letter had this:

Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="=?utf-8?q?
 =D0=BB=D0=B5=D1=82=D0=BE_=D0=BB=D0=B5=D1=82=D0=BE.png?="
Content-Type: image/png; name="=?utf-8?q?=D0=BB=D0=B5=D1=82=D0=BE_
 =D0=BB=D0=B5=D1=82=D0=BE.png?="

Note the added linebreak in the filename parameter of Content-Disposition header, same as with the original case, =?utf-8?q?R =C3=A9servation_Mingat, right before the first non-ASCII character.

I also send the same attachment only renamed in English, 'summer summer.png', and this time the header didn't have any of this:

Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="summer summer.png"
Content-Type: image/png; name="summer summer.png"

However, it's not limited to attachments: for emails, sent from aerc, I also notice some (not every, not always) non-ASCII subjects being displayed partly or not displayed at all.

For instance, this was the subject of the email I received (лето, ах лееето) in Russian, meaning something like summer, oh suuuummer)):

Subject: =?UTF-8?B?0LvQtdGC0L4sINCw0YUg0LvQtdC10LXRgtC+KQ==?=

I replied to this letter in aerc, the subject became Re: лето, ах лееето), and in the sent email it looked like this:

Subject: =?utf-8?q?Re:_=D0=BB=D0=B5=D1=82=D0=BE,_=D0=B0=D1=85_
 =D0=BB=D0=B5=D0=B5?= =?utf-8?q?=D0=B5=D1=82=D0=BE)?=

And in aerc the last леееето was missing, the subject looked like this: Re: лето, ах (Re: summer, oh), though in my webmail I could see it in full.

So, it indeed seems that aerc does something strange (like, inserts a linebreak or whatever) before some non-ASCII chars. And besides that, aerc also fails to display Subject in full if the named linebreak is present (well, can't really blame aerc here :).

So, it DOES support true color after all, it just checks $TERM for having truecolor in the name.

Still, italics support is missing (despite tcell sort of has it now). And also Vim's cursor shapes aren't working.

Based on this test shell script, aerc's :term seem to produce quite limited results, lacking the support of high and true color, italicized and dimmed text.

Here's a screenshot of aerc's :term on the left, usual shell on the right (both running in iTerm for macOS): https://i.imgur.com/rkrnITQ.png

Same as the contextual UI options, we should be able to override bindings per account.

Then, maybe not only per account but also per folder? Like, bind e to :archive flat if in INBOX but also bind e to :next-message if already in ARCHIVE.

Hi!

If my terminal emulator sends <F13> as ^[[1;2P, then aerc does understand it (e.g., I can map it like <F13> :cf INBOX<Enter> in binds.conf). But in this case :term doesn't get it (cat in :term shows nothing if I press <F13>).

However, if my terminal emulator sends ^[[25~ as <F13>, then :term captures it OK (cat shows the correct value, and I can map it Vim, for instance), but aerc itself doesn't respond to it at all.

As I understand, ^[[25~ is a VT220 sequence, and ^[O2P is the one from XFree86 xterm, so may be the problem is here?

Or maybe I'm just missing something extremely obvious, and there's an easy workaround here?

Thank you.

I believe this can be configured via postpone option in accounts.conf (and Drafts is just a default value).