~rjarry/aerc#137: 
how to handle notmuch + maildir integration

We had discussions about this over the mailing list and on IRC. To keep things a bit more tidy, I'll open an issue to track this.

mailing list discussion

One other thing that came up is whether to make a notmuch account just a flavour of maildir. The downside would be that we tie notmuch to maildir (and thus loose out on the ability to use it with the mh format), the upside would be much simpler codebase.

Status
REPORTED
Submitter
~ferdinandyb
Assigned to
No-one
Submitted
1 year, 5 months ago
Updated
3 months ago
Labels
breaking feature maildir notmuch

~inwit 1 year, 4 months ago

In summary, I see mainly three alternatives:

  1. Give the notmuch interface access to maildir folders. This is what we have now, sort of. As discussed in the aforementioned mailing list thread, maildir folders are currently recreated using notmuch queries. This implies that, on those 'fake' maildir folders, what we see are messages, not files, which is ok-ish if a message is supported by a single file in the maildir store, but it's bound to cause trouble if there are multiple files storing copies of a single message (inducing ambiguity in move/delete operations and search/filter commands).

  2. Give the maildir interface access to notmuch searches. This has been suggested several times and could be nice to have. However, accessing a notmuch database from the maildir worker would result in the same ambiguites.

  3. Full merge (single interface). We get rid of the notmuch worker (giving up mh support along the way, gasp) and we consider notmuch as merely an optional addition for the maildir worker, integrating all the functionality of notmuch into the maildir interface. The alternative (giving up the maildir worker in favour of the current notmuch interface) does not seem so appealing, since notmuch builds upon maildir.

In any of these three options, however, we still need to deal with the ambiguity of the pairs messages/files and folders/virtual folders, so we will need to address this anyway. A solution that has been discussed might be to impose a visual indication with sane defaults for both of them:

  • In the case of message/files listed in the message list, we could either add a new flag to the flag column, add a new column able to display the number of files present for each message (notmuch-emacs added a related functionality recently), or display files and messages with a different template. Possibly a combination of these solutions would be best.

  • In the case of folders, templating might be the easiest solution, but we could also split the dirlist and have a second area just for virtual folders. This solution would also be useful for operating on searches (saving them as permanent in the dirlist by adding them to the query-map file, for example, or even exporting a search to a folder or mbox).

~rockorager 1 year, 4 months ago

On Tue Feb 28, 2023 at 5:03 AM CST, ~inwit wrote:

  • In the case of folders, templating might be the easiest solution, but we could also split the dirlist and have a second area just for virtual folders. This solution would also be useful for operating on searches (saving them as permanent in the dirlist by adding them to the query-map file, for example, or even exporting a search to a folder or mbox).

I have a pretty good way to handle this one in the works. I am adding IANA special-use roles to the Directory model, and also adding a custom internal aerc one called "Query" (or "Search", still to be figured out). But that flag will allow us to determine the use of a folder - and for the case of "Query"/"Search"

  • limit some functionality that may be hard to determine the users intent (IE moving a message).

This functionality would extend beyond notmuch:

  1. global maildir search
  2. IMAP Esearch (multi-mailbox search, supported by gmail, office 365, fastmail,)
  3. gmail custom IMAP search (gmail exposes gmail-search syntax over imap in a custom extension, we could implement this)

-- Tim

~ferdinandyb 3 months ago

Register here or Log in to comment, or comment via email.