Hi Brandon,

On Tue Sep 3, 2024 at 9:16 PM EDT, Brandon Sprague wrote:
> Frequently I want to use the `:open-link` command, but the email has a dozen
> links that all look vaguely similar, and I want to just search for the unique
> bit (usually 'unsubscribe'), but the command palette matching seems to be
> prefix-based, which isn't useful in this context.

Are you aware of the :unsubscribe command? Often it will find the
unsubscribe link in the headers and prevent the need to comb through the
URLs yourself.

I do think fuzzy search would be useful as well, probably for all commands and
with a configuration option enabling/disabling it.

Hi folks,

I know that many of us use scripts like msmtpq to queue messages that
fail to send and automatically retry sending them later. I personally
find most of these scripts lacking in terms of integration with the mail
client and have my own custom script that improves the experience a bit
for me by indexing the send queue in notmuch so that I can at least view
it in aerc. I'm contemplating building some send queue functionality
directly into aerc, as described below, and welcome any feedback you
have.

To begin, here are my goals for the send queue's behavior:

- When a message fails to send, queue it to be sent later, regardless of

Hi Koni,

On Fri Aug 23, 2024 at 5:14 AM EDT, Koni Marti wrote:
> Add a -n flag to :search to select the immediate next search result from
> the current position in the messsage list. If not set, the (current)
> default behavior for :search is to jump to the very first search result.

In my opinion, it makes more sense to have this -n behavior be the
default and add a separate flag for the current default behavior. If
we're opposed to changing the default then I definitely think this flag
is a good addition.

> +	*-n*: Select the immediate next search result from the current position
> +		in the messsage list (only for *:search*).

Currently, the :reload command silently does nothing if no flags are
provided. Eliminate this confusion by reloading all reloadable configs
in the absence of flags.

Signed-off-by: Jason Cox <me@jasoncarloscox.com>
---
 commands/reload.go | 6 ++++++
 doc/aerc.1.scd     | 3 +++
 2 files changed, 9 insertions(+)

diff --git a/commands/reload.go b/commands/reload.go
index cd32bb36..2888ef90 100644
--- a/commands/reload.go
+++ b/commands/reload.go
[message trimmed]

On Tue Aug 20, 2024 at 1:10 PM EDT, Fabio Alessandro 'Fale' Locati wrote:
> Hi,
>
> I've noticed that if I add a single quote in the from field in the accounts.conf file it gets correctly rendered.
> In the other hand, if I add double quotes they are not rendered and they simply disappear.
> It looks like the rest of the string stays the same.
> I've also tried to put multiple double quotes in a row, but still they all disappear.
>
> Is there a work around this?

I spent a few minutes digging into this. It looks like the go-message
library we are using strips one level of double quotes, so A "B" C
becomes A B C. However, by adding escaped quotes within the quotes, we
can get go-message to turn A "\"B\"" C into A "B" C. But then aerc

On Thu Aug 8, 2024 at 4:49 AM EDT, Hugo Osvaldo Barrera wrote:
> For context, without my patch each time I mark a message as seen or
> deleted a message, I'd get CPU spike at 150% for ~60 seconds. With this
> patch, the operation took just 2s. Others couldn't properly reproduce my
> issue, so I'll open a ticket to track it properly before proposing
> another patch.

Have you tested without this patch but with commit c36ed72e4a59
("notmuch: speed up lastmod query")? It seems like that commit might
solve most of your performance problems by reducing the number of
messages that are re-indexed when the database changes.

On Wed Aug 7, 2024 at 5:07 PM EDT, Bence Ferdinandy wrote:
> 2024. aug. 7. 22:57:04 Jason Cox <me@jasoncarloscox.com>:
>
> > This reverts commit c56649fe5291b725f14b45550a68cc7d0dc16ff7.
>
> Shouldn't reverting be a revert commit by Robin?

I don't know; I didn't see the revert process documented anywhere, and I
thought the patch should be reverted, so I sent my own revert commit.
Totally fine by me if Robin wants to handle it, though!

This reverts commit c56649fe5291b725f14b45550a68cc7d0dc16ff7.

As discussed in the aerc-devel thread for the reverted patch, the
performance improvement comes with an issue: changes to message tags are
no longer immediately reflected in the UI. This issue occurs whether the
tags are modified from within aerc or externally with the notmuch CLI.
The message list also flickers any time tag changes are made.

Further, commit c36ed72e4a59 ("notmuch: speed up lastmod query")
dramatically reduces the number of messages which are re-indexed when
the database changes, likely eliminating the need for the reverted
performance improvement anyway.

Fixes: c56649fe5291 ("notmuch: don't reload all message on change")
[message trimmed]

It's useful to delete folders other than the current one. If a folder is
specified, delete that one; otherwise, delete the current one.

Changelog-added: Allow specifying the folder to delete with `:rmdir`.
Signed-off-by: Jason Cox <me@jasoncarloscox.com>
---

v2 -> v3: Check if the directory to be removed is empty, not the current
          directory.

v1 -> v2: Leave the logic to find a new directory to open as-is instead
          of refactoring it into a separate function. This tweak
          significantly reduces the diff size as requested by Moritz.
          Also move the remove function out of the Execute function to
[message trimmed]

On Sat Jun 15, 2024 at 5:27 AM EDT, Koni Marti wrote:
> On Fri Jun 14, 2024 at 12:22 PM CEST, Jason Cox wrote:
> > +	role := toRemove.Role
> > +
> >  	// Check for any messages in the directory.
> >  	if role != models.QueryRole && !acct.Messages().Empty() && !r.Force {
>
> We check with `acct.Messages().Empty()` if the folder that should be
> removed is empty. However, using `acct.Messages()` will always look at
> the message list of the *current* folder. If the current folder is
> empty, you could remove any other folder that contains messages without
> the force flag.
>
> You can reproduce with