Hi all,

First of all, I want to thank you for the hard work on Aerc, which, over
the past year since I last tried it, has become a fantastic email
client. I gave it another go yesterday, and for the first time, I feel I
can commit to using it. Once again: outstanding job!

Here are my thoughts on possible improvements to the notmuch+maildir
setup.

1. Virtual folders (aka queries) defined in `query-map` should take
precedence over folders sourced from the `maildir-store`. When there is
a conflict, with a query sharing the same name as a folder, it seems
reasonable to prioritize the query results. An option could be added to
the configuration file for users to select their preferred behavior.

2. For some reason, the `folder-map` is not functioning as anticipated.
I am unable to change folder names. I assume this feature is not
available in notmuch backend. Enabling the ability to show maildirs
under a different names (without extending this to queries, which seems
unnecessary) would complement the above suggestion nicely.

3. The `folders-exclude` option should apply solely to maildir folders
(right now, queries are filtered as well). Given that a defined query
implies its importance to the user, it likely means that it should not
be subject to filtering.

4. Threading. Neomutt offers a useful feature that, when threading is
enabled, it sources messages for the thread from all mailboxes, allowing
users to view not only incoming messages but also sent replies.
Implementing this in Aerc would be beneficial. 

5. In my configuration, I use a dot to denote nested folders; for
example, the 'Project.Archive' folder represents a subfolder of
'Project'. It would be beneficial for Aerc to display them in a nested
manner when `dirlist-tree` is enabled. To achieve this, we could
introduce a `dirlist-separator` option.

6. Regarding the operations of moving and copying messages, which were
extensively discussed recently on aerc-discuss [1] and aerc-develop [2]
mailing lists, I believe that a) moving and copying from both queries
and maildirs should be permitted, and b) moving into virtual folders
(queries) should be prohibited, with the clean messaging why the
operation was refused. I think this is already in place, except that
copying into a virtual folder fails without any notification. 

I agree with Bence Ferdinandy [3] that restricting the movement of
messages from virtual folders is unacceptable. I often create virtual
folders, for example with the `cf` command, to search for messages and
then archive them all or selectively.

7. If a message exists in multiple files, the user should have the option
to choose which copies to affect. When initiated from a maildir, the
copy within that folder ought to be preselected; if not, no copies
should be preselected by default. This approach should apply to delete,
move, and copy operations.

8. I would like a feature that triggers an external script whenever a
message is copied, moved, deleted, or modified, including when message
flags are changed. I maintain a script that updates Notmuch tags based
on messages' location and their flags.

9. The script is also invoked each time my maildirs synchronize with the
IMAP server (a process external to Aerc). It first removes certain tags,
then reapplies them with subsequent Notmuch commands. Although quick,
this process leads to noticeable message flickering in Aerc. An option
for event debouncing would be advantageous.

10. When it comes to message archiving, I maintain multiple Archive
folders. Each project has its own INBOX, along with subfolders for
message categorization and archiving. For instance, I have Project1
folder to which messages are routed using a sieve script executed by the
IMAP server. Then I may have Project1.ImportantTopic and
Project1.Archive folders. I like Arec to to automatically select the
Project1.Archive folder for archiving messages from the Project1 folder
and its subfolders. Should a corresponding Project1.Archive folder not
exist, Aerc should default to the global Archive folder.

I guess this could be achieved with the trick suggested by Bence, but I
haven't tried this yet:
> :mv {{index (.Filename | split ("/")) 4}}/Archive <Enter>`

These are my thoughts after using Aerc for two days. I like it quite a
bit and have decided to stick with it for a while. If you have any
thoughts on the suggested improvements, let’s discuss them. I haven't
checked out the source code yet, but I plan to do so in the coming days.
If you have any suggestions on where to start or which of the above
improvements should be prioritized, I would greatly appreciate your
insights.

Best,
Radek

[1] https://lists.sr.ht/~rjarry/aerc-discuss/%3CCYQMOVG811L1.1HNN3PYR0FLAH%40ferdinandy.com%3E
[2] https://lists.sr.ht/~rjarry/aerc-devel/%3C20240123050837.324281-2-me%40jasoncarloscox.com%3E#%3CCYLYFTU7KBSP.1FWIU3WMF5F6J@ferdinandy.com%3E
[3] https://lists.sr.ht/~rjarry/aerc-discuss/%3CCYQMOVG811L1.1HNN3PYR0FLAH%40ferdinandy.com%3e#%3CCYQO1CUJTSBG.PJMV3ZMGI13Q@ferdinandy.com%3E

Hi Radek,

This is quite a list! Lots of good thoughts here.

On Thu Feb 8, 2024 at 1:48 PM EST, Radosław Kintzi wrote:
> First of all, I want to thank you for the hard work on Aerc, which, over
> the past year since I last tried it, has become a fantastic email
> client. I gave it another go yesterday, and for the first time, I feel I
> can commit to using it. Once again: outstanding job!

Glad that you're enjoying it!

> 1. Virtual folders (aka queries) defined in `query-map` should take
> precedence over folders sourced from the `maildir-store`. When there is
> a conflict, with a query sharing the same name as a folder, it seems
> reasonable to prioritize the query results. An option could be added to
> the configuration file for users to select their preferred behavior.

Yes, I like this.

> 2. For some reason, the `folder-map` is not functioning as anticipated.
> I am unable to change folder names. I assume this feature is not
> available in notmuch backend. Enabling the ability to show maildirs
> under a different names (without extending this to queries, which seems
> unnecessary) would complement the above suggestion nicely.

Indeed, folder-map doesn't seem to be implemented for notmuch. The
maildir and IMAP backends do it via a middleware that gets setup in the
worker's handleConfigure function, but there's no mention of it in the
notmuch worker. The aerc-accounts man page does have a little note
(which is easy to miss) saying "Supported backends: imap, maildir."

> 3. The `folders-exclude` option should apply solely to maildir folders
> (right now, queries are filtered as well). Given that a defined query
> implies its importance to the user, it likely means that it should not
> be subject to filtering.

A few potential uses for excluding query folders:

1. Sharing the same folder map across multiple aerc accounts
corresponding to different notmuch profiles or different values of
maildir-account-path.

2. Hiding a query folder from the UI by default while making it easy to
open on demand via :cf <folder>. (I just tested; this works.) This could
be especially useful considering we don't currently load the notmuch
config and therefore don't support named queries.

That said, I would like a way to easily exclude all maildir folders. I
currently have to enumerate them all (or craft regexes) in
folders-exclude.

> 4. Threading. Neomutt offers a useful feature that, when threading is
> enabled, it sources messages for the thread from all mailboxes, allowing
> users to view not only incoming messages but also sent replies.
> Implementing this in Aerc would be beneficial. 

Check out the show-thread-context config option and
:toggle-thread-context commands. I think these do what you're asking
for.

> 5. In my configuration, I use a dot to denote nested folders; for
> example, the 'Project.Archive' folder represents a subfolder of
> 'Project'. It would be beneficial for Aerc to display them in a nested
> manner when `dirlist-tree` is enabled. To achieve this, we could
> introduce a `dirlist-separator` option.

This is how maildir++ works, right? We already support maildir++ with
the normal maildir backend, so it seems reasonable to have the notmuch
backend support it as well.

> 7. If a message exists in multiple files, the user should have the option
> to choose which copies to affect. When initiated from a maildir, the
> copy within that folder ought to be preselected; if not, no copies
> should be preselected by default. This approach should apply to delete,
> move, and copy operations.

I like this as a default. It would be nice to support other options, as
discussed previously, as well.

> 8. I would like a feature that triggers an external script whenever a
> message is copied, moved, deleted, or modified, including when message
> flags are changed. I maintain a script that updates Notmuch tags based
> on messages' location and their flags.

Have you checked out the hooks? (See the hooks section of
aerc-config(5).) I don't think we support all of the events you want,
but several of them are there. We might need to add more variables to
existing hooks for your proposed use case as well.

> 9. The script is also invoked each time my maildirs synchronize with the
> IMAP server (a process external to Aerc). It first removes certain tags,
> then reapplies them with subsequent Notmuch commands. Although quick,
> this process leads to noticeable message flickering in Aerc. An option
> for event debouncing would be advantageous.

The notmuch backend already does debouncing -- search for
watcherDebounce in worker/notmuch/worker.go. Looks like it's currently
set to 50ms. Making this duration user configurable could be nice.

> 10. When it comes to message archiving, I maintain multiple Archive
> folders. Each project has its own INBOX, along with subfolders for
> message categorization and archiving. For instance, I have Project1
> folder to which messages are routed using a sieve script executed by the
> IMAP server. Then I may have Project1.ImportantTopic and
> Project1.Archive folders. I like Arec to to automatically select the
> Project1.Archive folder for archiving messages from the Project1 folder
> and its subfolders. Should a corresponding Project1.Archive folder not
> exist, Aerc should default to the global Archive folder.
>
> I guess this could be achieved with the trick suggested by Bence, but I
> haven't tried this yet:
> > :mv {{index (.Filename | split ("/")) 4}}/Archive <Enter>`

Interesting. I think templates may be the best way to do this, given
that different people are likely to have slightly different methods of
determining which is the correct archive folder. You could make Bence's
template a bit fancier to support a fallback as well.

> These are my thoughts after using Aerc for two days. I like it quite a
> bit and have decided to stick with it for a while. If you have any
> thoughts on the suggested improvements, let’s discuss them. I haven't
> checked out the source code yet, but I plan to do so in the coming days.
> If you have any suggestions on where to start or which of the above
> improvements should be prioritized, I would greatly appreciate your
> insights.

We'd love to have you contribute and are happy to help along the way if
you need it!

Best,
Jason

On 09/02/2024, 14:14, Jason Cox wrote:
> This is quite a list! Lots of good thoughts here.
+1

> On Thu Feb 8, 2024 at 1:48 PM EST, Radosław Kintzi wrote:
> > 1. Virtual folders (aka queries) defined in `query-map` should take
> > precedence over folders sourced from the `maildir-store`. When there is
> > a conflict, with a query sharing the same name as a folder, it seems
> > reasonable to prioritize the query results. An option could be added to
> > the configuration file for users to select their preferred behavior.
>
> Yes, I like this.

I do like it too. Not so sure about the prioritizing, my first thought is to do the opposite: prioritize folders over queries, but making it configurable sounds good to me. I'd add that these two types of folders (queries and folder-queries) should be visually distinguishable in the dirlist, and also from live-queries (queries issued at runtime).

(...)
> > 4. Threading. Neomutt offers a useful feature that, when threading is
> > enabled, it sources messages for the thread from all mailboxes, allowing
> > users to view not only incoming messages but also sent replies.
> > Implementing this in Aerc would be beneficial. 
>
> Check out the show-thread-context config option and
> :toggle-thread-context commands. I think these do what you're asking
> for.
(...)

Now that we're in asking mode, it'd be super nice to be able to :toggle-thread-context for a single thread, instead of for all of them at the same time.

(...)
> > 7. If a message exists in multiple files, the user should have the option
> > to choose which copies to affect. When initiated from a maildir, the
> > copy within that folder ought to be preselected; if not, no copies
> > should be preselected by default. This approach should apply to delete,
> > move, and copy operations.
>
> I like this as a default. It would be nice to support other options, as
> discussed previously, as well.

There might be more than one copy in the same maildir folder, which invalidates the preselection proposal in those cases. But yes, this is the way.

(...)
> > These are my thoughts after using Aerc for two days. I like it quite a
> > bit and have decided to stick with it for a while. If you have any
> > thoughts on the suggested improvements, let’s discuss them. I haven't
> > checked out the source code yet, but I plan to do so in the coming days.
> > If you have any suggestions on where to start or which of the above
> > improvements should be prioritized, I would greatly appreciate your
> > insights.
>
> We'd love to have you contribute and are happy to help along the way if
> you need it!
+1. It's so nice to see more notmuchers getting onboard! :)