As far as I understand, you can compile
aercwith the original
replace github.com/gdamore/tcell => git.sr.ht/~sircmpwn/tcell v0.0.0-20190807054800-3fdb6bc01a50from
go get github.com/gdamore/tcell@master
It doesn't seem to solve any of the problems, though: both italic and truecolor (without abusing
TERM) still will not function.
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)):
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 :).
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
:archive flatif in INBOX but also bind
:next-messageif already in ARCHIVE.
If my terminal emulator sends
^[[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
:termdoesn't get it (
:termshows nothing if I press
However, if my terminal emulator sends
:termcaptures it OK (
catshows 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
^[[1;2Pis something else, so may be the problem is here?
Or maybe I'm just missing something extremely obvious, and there's an easy workaround here?
EDIT: Still true if using the original