~john1doe


#468 ui folder/account specific sorting doesn't seem to work (maildir) 10 months ago

Ticket created by ~john1doe on ~sircmpwn/aerc2

As of commit a1467af, adding something like this to aerc.conf doesn't work (both for ui:account and ui:folder):

[ui:account=ACCOUNTNAME]
sort="from"

While adding something like this does:

[ui:account=ACCOUNTNAME]
index-format=%D

(This is the maildir backend, so issuing the :sort from command manually does work.)

#460 Problems with folders with square brackets (maildir) 11 months ago

Comment by ~john1doe on ~sircmpwn/aerc2

REPORTED RESOLVED FIXED

#460 Problems with folders with square brackets (maildir) 11 months ago

bug added by ~john1doe on ~sircmpwn/aerc2

#460 Problems with folders with square brackets (maildir) 11 months ago

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:

  1. 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

  2. This is the contents of the destination folder, [test] after the failed cp command:

    ~/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 from 1604464143.citron.local.949571000212ece86f727c1ec0dd4a2, to 1604464143.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".

#416 aerc's :term doesn't seem to support high/true color, some text decorations 1 year, 2 months ago

Comment by ~john1doe on ~sircmpwn/aerc2

As far as I understand, you can compile aerc with the original tcell:

  • remove replace github.com/gdamore/tcell => git.sr.ht/~sircmpwn/tcell v0.0.0-20190807054800-3fdb6bc01a50 from go.mod file
  • run 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.

#423 Error when sending mail with accents in the filename of an attachment 1 year, 3 months ago

Comment by ~john1doe on ~sircmpwn/aerc2

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

#423 Error when sending mail with accents in the filename of an attachment 1 year, 3 months ago

Comment by ~john1doe on ~sircmpwn/aerc2

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

#423 Error when sending mail with accents in the filename of an attachment 1 year, 3 months ago

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.

#423 Error when sending mail with accents in the filename of an attachment 1 year, 3 months ago

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 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 :).

#416 aerc's :term doesn't seem to support high/true color, some text decorations 1 year, 3 months ago

Comment by ~john1doe on ~sircmpwn/aerc2

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.