Previously the output param was ignored
---
 server.go | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/server.go b/server.go
index e47b0b3..48cfc7c 100644
--- a/server.go
+++ b/server.go
@@ -60,7 +60,7 @@ func (l logger) Debugf(format string, v ...interface{}) {
 
 func NewLogger(out io.Writer, debug bool) Logger {
 	return logger{
-		Logger: log.New(log.Writer(), "", log.LstdFlags),
[message trimmed]

Your first problem would be to track the message count in the first place...
At least on imap the account only fetches messages from the open mailbox.

On the notmuch worker you at least have the counts right and then it shouldn't
be too much of a problem.

Do note however that aerc is currently without a maintainer, so getting patches
merged might be interesting. If you feel like it ping Drew in #aerc-dev on libera
or via email.

On Sun, May 16, 2021 at 05:14:29PM +0100, Jonathan Bartlett wrote:
> I will rebase the changes, should I submit at v4 again or v5 now?

V5 will do

Hi,
You seem to have a bit of a problem as to how the email patch submission works.
Maybe follow that tutorial here: https://git-send-email.io/ ?

Please rebase your changes, as explained in that tutorial.

Also, not sure why you tend to send multiple patches in very short time increments...
Maybe slow down a tad on the submission?

Cheers,
Reto

Hi,
Thank you for the patch.
I like the functionality this wants to implement, however I think this patch
could be improved a bit.

For starters, it has severe whitespace issues, please run go fmt on anything you
send to the list. Also, do remove debug statements please ;)

> +    fmt.Printf("%:v", config.Bindings.MessageList.Account)

Second, could we structure this a bit like the styles? It's the same problem
and I think a bit cleaner than what you are doing.

In my opinion it would be nice if we don't invent yet another notation, meaning

Hi,
Thanks for the patches, appreciated.

On Fri, May 14, 2021 at 09:44:41PM -0400, Zach DeCook wrote:
> @@ -49,8 +50,13 @@ func (sel *Selector) Draw(ctx *ui.Context) {
>  				style = sel.uiConfig.GetStyle(config.STYLE_SELECTOR_CHOOSER)
>  			}
>  		}
> -		x += ctx.Printf(x, 1, style, "[%s]", option)
> -		x += 5
> +		if x > 2 && x + len(option) >= ctx.Width() {
> +			x = 2
> +			// Warning: context may not be tall enough to wrap.
> +			y += 1

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
[message trimmed]

Hallo Wagner,

On Mon, Apr 26, 2021 at 12:58:47AM -0300, wagner riffel wrote:
> Hey Reto, friendly pinging, in case you missed my reply, it's been
> over 15 days since your last reply and I'm willing to work on changes
> to get this merged.

Sorry, fell through the cracks.

So...
I can't reproduce the error anymore with the event loop stalling at least in
the notmuch worker.

Can you try what happens if you simply remove the double emit of the event?

Hi there,

On Mon, Apr 12, 2021 at 04:24:35PM -0700, Clayton Craft wrote:
> 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.

Merged, thank you :)

> What if instead we only deactivate the warning when only `*-cred-cmd`
> options are used?

Hm, that might work.
But that means bailing out as soon as even one account doesn't have it.

Cheers,
Reto