Hello,

Thanks a lot for your answers, I'm happy to have received such thoughtful replies. Like you both pointed out, and from what I get, Notmuch works with message-ids, and since it may happen that several files in different folders have the same message-id, it explains what I was seeing.

My goal was to try to sync somehow how emails on my computer are organized using Notmuch and its tags with folders on the IMAP servers of the many email accounts I'm syncing to my ~/mail dir, using mbsync. I guess this is a common endeavour some people want, so for example if you browse one of your email account using a webmail interface, or an app on your phone, then there is some continuity between how your emails are sorted on your computer and how you find them on other interfaces. But I also see that this isn't that simple to implement. Being centered on message-ids, Notmuch doesn't seem to easily be able to recognize on which email account an email is (like in cases where one of my email account send an email to another of my account, or when some of my accounts receive the same email from somewhere else... basically, when there are duplicates). I also found out that moving email files might disrupt mbsync, so it is another issue I would need to look at.

I also understand the important differences between organizing emails using tags, and using folders. I just wanted to see if, with some shell scripting, I could arrange something somewhat similar. But it seems harder to do than I hoped.

I am still new to Notmuch, I use it on Emacs, maybe my efforts weren't necessary, and so I will keep using it and see how my needs and preferences go.

Thanks again for your replies, much appreciated!
Renaud


Le mar. 14 mai 2024, à 04 h 19, Michael J Gruber <michaeljgruber+grubix+git@gmail.com> a écrit :
Am Mo., 13. Mai 2024 um 23:38 Uhr schrieb Carl Worth <cworth@cworth.org>:
>
> Hi Renaud,
>
> I was able to see similar behavior in my own mail store. And I agree
> that this behavior is confusing!
>
> The documentation for the --files option of notmuch search documents the
> cause (and predicts that this will be confusing):
>
....
> In general, I'm not a fan of software documenting "this may be
> confusing". That suggests the authors of the documentation know that the

:-)

> software is not behaving as the user intends, so it would be preferable
> for the software to behave as intended. That said, I also understand the
> implementation details that lead to this behavior. So I wouldn't be
> opposed to improving the behavior of notmuch to reduce this behavior,
> (but that implementation might not be trivial or even fully feasible).

I wouldn't call it an implementation detail in this case, though,
rather than the guiding principle of notmuch: it is all about
*messages* as identified by a mid.

Consequently, notmuch stores information by message, searches by
message and outputs information by message. This in turn has
consequences, for better or worse, e.g. when different mail files with
the same mid have different (maildir) flags. But without grasping the
main guiding principle you'll get confused sooner or later.

As soon as you introduce "do what I mean" into the CLI design the
outcome depends on the "I" implementing it, who may "mean" very
different things compared to the "I" using the CLI. This creates
confusion which cannot be resolved by pointing out a guiding
principle, but rather "when we do x it is often convenient to imply y
and that's why do z". You can witness that to some extent in git's
CLI.

Also, dwim'ing in the case at hand seems difficult - you'd have to
extract "path:" tokens from a possibly complex query, track logical
operators applying to them and filter the output accordingly. Compare
that to "find -type f dirWhichIWant" which would have solved OP's use
case ...

Cheers
Michael