go-messages GenerateMessageID does generate the Message ID based on the hostname of the local machine. This is ok in this context because the lib does not know really anything of the surroundings. But aerc does know about the sender domain and could use this instead of the hostname. This also aligns with the recommendation of RFC4322 to use a unique domain name, to ensure the uniqueness of the whole Message ID [1]. A side effect of this change is that it also improves the score of some spam filters a bit, if an E-Mail has a fully qualified domain name after the @. This patch fixes https://todo.sr.ht/~sircmpwn/aerc2/526 [1] https://www.rfc-editor.org/rfc/rfc5322.html#section-3.6.4
There was some bug which could be worked around by double emitting an event. However that proofed to be brittle: We send the first message here from the worker goroutine: https://git.sr.ht/~sircmpwn/aerc/tree/a5553438/item/worker/maildir/worker.g= o#L306 Then Tick() is waked in the main goroutine and calls ProcessMessage: https://git.sr.ht/~sircmpwn/aerc/tree/a5553438/item/widgets/account.go#L100 ProcessMessage in the main goroutine reads types.Message state with msg.getId() and msg.InResponseTo(): https://git.sr.ht/~sircmpwn/aerc/tree/a5553438/item/worker/types/worker.go#= L74-76 Meanwhile in the worker goroutine we call PostMessage for a second time with a pointer that points to the *same* previous message that ProcessMessage is reading: https://git.sr.ht/~sircmpwn/aerc/tree/a5553438/item/worker/maildir/worker.g= o#L306 The second PostMessage call makes writes to message while ProcessMessage in the main goroutine is possibly reading: https://git.sr.ht/~sircmpwn/aerc/tree/a5553438/item/worker/types/worker.go#= L59 This led to a data race in the event loop Reported-By: Wagner Riffel <w@104d.net>
It makes absolutely no sense to copy over the default template from aerc.conf when the syntax is invalid and our ini parser fails. The only valid case to do that is if the file is actually missing.
This fixes a substantial performance issue when scrolling emails with
long/complicated contents, where scrolling down a single line can take
something like hundreds of ms before the screen is updated to reflect
the scroll. It's really bad if the email has lots of columns, e.g. like
if it's an html email that was passed through a filter (w3m, etc) to
render it.
Using pprof, I found that the multiple calls to vterm.ScreenCell.Attrs()
in styleFromCell were really really expensive. This patch replaces them
with a single call.
Here's a before and after with a simple, but very manual test of opening
a large email with contents that went through a w3m filter and
continuously scrolling up and down over and over for ~30 seconds:
*** Before:
----------------------------------------------------------+-------------
flat flat% sum% cum cum% calls calls% + context
----------------------------------------------------------+-------------
28.25s 100% | git.x2esr.x2eht..z2f..z7esircmpwn..z2faerc..z2fwidgets.PartSwitcher.Draw
0 0% 99.94% 28.25s 82.31% | git.x2esr.x2eht..z2f..z7esircmpwn..z2faerc..z2fwidgets.PartViewer.Draw
28.25s 100% | git.x2esr.x2eht..z2f..z7esircmpwn..z2faerc..z2fwidgets.Terminal.Draw
----------------------------------------------------------+-------------
28.25s 100% | git.x2esr.x2eht..z2f..z7esircmpwn..z2faerc..z2fwidgets.PartViewer.Draw
0 0% 99.94% 28.25s 82.31% | git.x2esr.x2eht..z2f..z7esircmpwn..z2faerc..z2fwidgets.Terminal.Draw
19.23s 68.07% | git.x2esr.x2eht..z2f..z7esircmpwn..z2faerc..z2fwidgets.Terminal.styleFromCell
6.04s 21.38% | github.x2ecom..z2fddevault..z2fgo..z2dlibvterm.Screen.GetCellAt
1.38s 4.88% | git.x2esr.x2eht..z2f..z7esircmpwn..z2faerc..z2flib..z2fui.Context.Printf
0.62s 2.19% | runtime.mapassign
0.43s 1.52% | runtime.mapaccess2
0.20s 0.71% | runtime.newobject
0.19s 0.67% | runtime.callers (inline)
0.07s 0.25% | runtime.makeslice
0.07s 0.25% | runtime.mallocgc
----------------------------------------------------------+-------------
19.23s 100% | git.x2esr.x2eht..z2f..z7esircmpwn..z2faerc..z2fwidgets.Terminal.Draw
0 0% 99.94% 19.23s 56.03% | git.x2esr.x2eht..z2f..z7esircmpwn..z2faerc..z2fwidgets.Terminal.styleFromCell
19.21s 99.90% | github.x2ecom..z2fddevault..z2fgo..z2dlibvterm.ScreenCell.Attrs
*** After:
----------------------------------------------------------+-------------
flat flat% sum% cum cum% calls calls% + context
----------------------------------------------------------+-------------
0.31s 100% | git.x2esr.x2eht/~sircmpwn/aerc/widgets.Terminal.Draw
0 0% 99.87% 0.31s 1.33% | github.x2ecom/ddevault/go-libvterm.NewPos
0.25s 80.65% | runtime.callers (inline)
0.04s 12.90% | runtime.gomcache (inline)
----------------------------------------------------------+-------------
8.40s 100% | github.x2ecom/ddevault/go-libvterm.Screen.GetCellAt
0 0% 99.87% 8.40s 36.11% | github.x2ecom/ddevault/go-libvterm.Screen.GetCell
7.14s 85.00% | github.x2ecom/ddevault/go-libvterm._cgoCheckPointer
0.54s 6.43% | runtime.callers (inline)
0.35s 4.17% | runtime.exitsyscall
0.11s 1.31% | runtime.deferprocStack
0.07s 0.83% | doentersyscall
0.07s 0.83% | runtime.getg
0.05s 0.6% | runtime.casgstatus
0.03s 0.36% | _init
0.03s 0.36% | runtime.gomcache (inline)
----------------------------------------------------------+-------------
8.46s 100% | git.x2esr.x2eht/~sircmpwn/aerc/widgets.Terminal.Draw
0 0% 99.87% 8.46s 36.37% | github.x2ecom/ddevault/go-libvterm.Screen.GetCellAt
8.40s 99.29% | github.x2ecom/ddevault/go-libvterm.Screen.GetCell
0.06s 0.71% | runtime.callers (inline)
----------------------------------------------------------+-------------
0.31s 100% | git.x2esr.x2eht/~sircmpwn/aerc/widgets.Terminal.styleFromCell
0 0% 99.87% 0.31s 1.33% | github.x2ecom/ddevault/go-libvterm.ScreenCell.Attrs
)
Instead of panic when compiling a regular expression, return it up Signed-off-by: wagner riffel <w@104d.net>