Ticket created by ~john1doe on ~sircmpwn/aerc2
As of commit a1467af, adding something like this to
aerc.confdoesn't work (both forui:accountandui:folder):[ui:account=ACCOUNTNAME] sort="from"While adding something like this does:
[ui:account=ACCOUNTNAME] index-format=%D(This is the
maildirbackend, so issuing the:sort fromcommand manually does work.)
Comment by ~john1doe on ~sircmpwn/aerc2
Fixed upstream: https://github.com/emersion/go-maildir/issues/10
REPORTED RESOLVED FIXED
bug added by ~john1doe on ~sircmpwn/aerc2
Ticket created by ~john1doe on ~sircmpwn/aerc2
On maildir backend, aerc seems to fail when copying/moving messages to a folder, which has square brackets in its name, like
[test].When I try to copy a message to such a folder, it reports the following error:
could not copy message 969: maildir: key 1604464143.citron.local.949571000212ece86f727c1ec0dd4a matches 0 files.And if I take a look at the filesystem, then I notice the following:
This is the contents of the source folder,
test:~/Maildir/test/cur> ls -la total 68K -rw-r--r-- 1 s 31K Nov 4 00:31 1604462839.M934234P89860Q2.citron.local:2, -rw-r--r-- 1 s 15K Nov 3 21:37 1604462852.M72207P89860Q3.citron.local:2, -rw-r--r-- 1 s 4.1K Nov 3 22:32 1604462855.M585571P89860Q4.citron.local:2, -rw-r--r-- 1 s 3.0K Nov 3 20:53 1604462855.M600502P89860Q5.citron.local:2, -rw-r--r-- 1 s 2.1K Nov 3 20:51 1604462855.M612264P89860Q6.citron.local:2, -rw-r--r-- 1 s 3.6K Nov 3 20:50 1604462855.M624851P89860Q7.citron.local:2,S
This is the contents of the destination folder,
[test]after the failedcpcommand:~/Maildir/[test]/cur> dir total 4.0K -rw------- 1 s 2.1K Nov 4 06:29 1604464143.citron.local.949571000212ece86f727c1ec0dd4a2,
And if I
:cf [test], the directory sidebar will say that I have 1 message there but the folder itself will display none. However, if in the shell I will rename this only message in the[test]folder from1604464143.citron.local.949571000212ece86f727c1ec0dd4a2,to1604464143.citron.local.949571000212ece86f727c1ec0dd4a:2,then I will be able to see and open the message (or copy it from[test]to any other folder) just fine.So, the problem seems to arise when copying/moving TO a folder with the square brackets. More precisely, a colon in the name of the message somehow gets "eaten".
Comment by ~john1doe on ~sircmpwn/aerc2
As far as I understand, you can compile
aercwith the originaltcell:
- remove
replace github.com/gdamore/tcell => git.sr.ht/~sircmpwn/tcell v0.0.0-20190807054800-3fdb6bc01a50fromgo.modfile- run
go get github.com/gdamore/tcell@masterIt doesn't seem to solve any of the problems, though: both italic and truecolor (without abusing
TERM) still will not function.
Comment by ~john1doe on ~sircmpwn/aerc2
From my side, it looks like so. Thank you very much :)
Comment by ~john1doe on ~sircmpwn/aerc2
Not only in the attachment filename but also in the Subject (and other fields may be affected, too).
Comment by ~john1doe on ~sircmpwn/aerc2
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.
Comment by ~john1doe on ~sircmpwn/aerc2
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 likesummer, 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 :).
Comment by ~john1doe on ~sircmpwn/aerc2
So, it DOES support true color after all, it just checks
$TERMfor havingtruecolorin the name.Still, italics support is missing (despite
tcellsort of has it now). And also Vim's cursor shapes aren't working.
