Note that, until we get color configuration, this means that the user *must*
have the %Z verb in the index format else it'll be horribly confusing
as no visual indication is provided
Rather than showing completions inline in the text input, show them in a
popover which can be scrolled by repeatedly pressing the tab key. The
selected completion can be executed by pressing enter.
A popover is a special UI element which can be layered over the rest of
the UI (i.e. it is painted last) and can fall anywhere on the screen,
not just with the bounds of its parent's viewport/context. With these
special abilities comes the restriction that only one popover may be
visible on screen at once.
Popovers are requested from the UI context passed to Draw calls and
specify the anchor point and the desired dimensions. The popover is then
fit to the available space and placed relative to the anchor point.
This fixes an upstream issue where improperly named maildir files could
cause a panic. Now, we simply show an error and don't display the
message if the backing file is not named according to the maildir spec.
A panic could happen when multiple delete messages are sent one after
another without waiting until there are no messages left to be deleted:
panic: runtime error: makeslice: len out of range
goroutine 1 [running]:
git.sr.ht/~sircmpwn/aerc/lib.(*MessageStore).Update(0xc000592e00, 0xa8fe60, 0xc0003340f0)
/go/src/git.sr.ht/~sircmpwn/aerc/lib/msgstore.go:222 +0x5b8
git.sr.ht/~sircmpwn/aerc/widgets.(*AccountView).onMessage(0xc0000a0460, 0xa8fe60, 0xc0003340f0)
/go/src/git.sr.ht/~sircmpwn/aerc/widgets/account.go:251 +0x307
git.sr.ht/~sircmpwn/aerc/widgets.(*AccountView).Tick(0xc0000a0460, 0xc0001496b0)
/go/src/git.sr.ht/~sircmpwn/aerc/widgets/account.go:90 +0xa1
git.sr.ht/~sircmpwn/aerc/widgets.(*Aerc).Tick(0xc0000a9f40, 0xc000020501)
/go/src/git.sr.ht/~sircmpwn/aerc/widgets/aerc.go:123 +0x91
main.main()
/go/src/git.sr.ht/~sircmpwn/aerc/aerc.go:182 +0x5bf
The make that blows up is:
uids := make([]uint32, len(store.uids)-len(msg.Uids))
This change simply checks whether the make is going to be valid before
starting to work on the actual delete. If there are more messages queued
to be deleted than what's left in the store, then we're obviously in an
inconsistent state, ask for an update and break.
A new config options for accounts.conf (folders-sort) was added to
allow a user to choose which folders should be shown on top.
My use case was to avoid stepping into heavy, but rarely viewed folders
when cycling through other often accessed ones.
To test add this to your account.conf:
folders-sort = INBOX,Sent,Archive
INBOX, Sent and Archive should then show at the top of your dirlist,
and all other folders should come next in alphabetical order.
Very important fix. Remove garbage from reply message headers. Till
now all Original fields were send in reply, which we do not want and could
lead to uncorrect email message.
Hi!
This patch will fix missing filename if it is RFC2231 encoded with charset
different then ASCII or UTF8. Example how it looks like in mail:
Content-Type: application/pdf;
name="=?UTF-8?Q?Opis_przedmiotu_zam=c3=b3wienia_-_za=c5=82=c4=85cznik_nr_1?=
=?UTF-8?Q?=2epdf?="
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename*0*=iso-8859-2''%4F%70%69%73%20%70%72%7A%65%64%6D%69%6F%74%75%20;
filename*1*=%7A%61%6D%F3%77%69%65%6E%69%61%20%2D%20%7A%61%B3%B1%63%7A%6E;
filename*2*=%69%6B%20%6E%72%20%31%2E%70%64%66
Yes, this should be forbidden :-). Anyway, best solotion in such cases
is to failback to Content-Type name. I am not sure if it is guaranted to
be there, but probably it will.
Leszek
Me again,
this time fixing encoding of subjects and attachments. It was problem in
IMAP backend. While other backends user MessageInfo() function which
generates MessageInfo decoded via go-message methodes, IMAP worker is
creating MessageInfo directly, so all non-utf8 subjects and filenames
were in raw form.
This patch fixes it. Not sure if we should care about errors (if
DecodeHeader fails it returns raw string back).
>From what I see, this should solve all encoding problem (tested only
IMAP). So, now I can focus on features. ;-)
Have a great weekend!
Leszek
Hello guys,
on the hunt for bugs related to wrong encoding. This patch is fixing
reply to non-utf8 messages.
We were using global message headers instead of part specific. In
practice header were often something like:
multipart; boundry=...
where there should be:
text/plain; charset=...
Fixed also missing SubType.
Have great weekend!
Leszek
This patch should fix encoding problem with non-utf8 text/plain mime.
It is now correctly convert to utf8 before sending to pager. It will
also solve quoting such mails.
Leszek
Hi everyone!
On my system I have strict umask set, so make install creates them
unreadable by non-root. This trivial fix ensures, that directories are
created as expected.
Leszek
This patch parses the processed template for headers and populates
matching header editors.
Those are then stripped from the template body before prepending the template
and remaining header fields to the composer content.
The main motivation for this is keeping receiver, sender and subject
lines in the template file and generating the message subject from the
date.
This addresses occasional crashes when a `MessageInfo` event reached the message
store before `DirectoryContents`, particularly on slower (imap) accounts.
Pressing `Enter` on a view that has not yet loaded messages (e.g. at
startup) would return `nil` from `Selected()`. Accessing `msg.Uid` on a
`nil` reference crashes aerc.
This patch moves the `msg == nil` check before accessing `msg.Uid` thus
avoiding the crash.
To test this patch repeatedly press `Enter` on startup.
Parse the processed template for headers and populates matching header
editors accordingly.
Those are then stripped from the template body before prepending it
and remaining header fields to the composer content.
The motivation for this is keeping receiver, sender and subject
lines in the template file and generating the message subject with the
date functions.
The editor and pager were not properly being reaped, causing resource
leakage whenever a user replies to a message.
Signed-off-by: Kevin Kuehler <keur@xcf.berkeley.edu>
Allowing the user to view deleted messages creates all sorts of race
conditions. The most devious race condition is pv.source can be set to a
nil while another PartViewer is still running a goroutine in
attemptCopy.
Here is a trace when this happens.
goroutine 76 [running]: io.copyBuffer(0x7f8ad02641d0, 0xc00040f590, 0x0,
0x0, 0xc0007cc000, 0x8000, 0x8000, 0x0, 0x0, 0x8b3d60)
/usr/lib/go/src/io/io.go:402 +0x101 io.Copy(...)
/usr/lib/go/src/io/io.go:364
git.sr.ht/~sircmpwn/aerc/widgets.(*PartViewer).attemptCopy.func4(0xc00017efd0,
0xc0004da7c0) /home/keur/repos/aerc/widgets/msgviewer.go:576 +0x611
created by git.sr.ht/~sircmpwn/aerc/widgets.(*PartViewer).attemptCopy
/home/keur/repos/aerc/widgets/msgviewer.go:544 +0x144
We could add a guard in store.FetchBodyPart to only call the callback
when msg.Part.Reader != nil, but we still get a hanging pager. Therefore
it seems more reasonable to disable this completely.
Signed-off-by: Kevin Kuehler <keur@xcf.berkeley.edu>
