Re: I don't understand the results of this search query, is this a bug?

[Michael J Gruber <michaeljgruber+grubix+git@gmail.com>]

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