Frederick Eaton <frederik@ofb.net> writes: > it is rather common to receive multiple distinct messages with the > same ID, for example when someone replies to a mailing list post and > Cc's me, and I would want these to be separately viewable (they are > linked together ith an "=" in the Mutt thread view) for security > reasons' Just for the record, both copies are also separately viewable in the Emacs interface in current notmuch. I don't know how other front ends handle it. > If Notmuch is meant to function as an abstraction layer over message > files stored on the file system, then why doesn't it provide a > standard way to go from file paths to Notmuch messages? Although I think notmuch as it exists is far from "an abstraction layer", the specific feature request seems reasonable. It would need someone who wants it to get familiar with the low level implementation details of notmuch. In particular it would require writing a database upgrade and having a new version of the database schema. It might happen eventually as a side effect of reworking the way threading works in notmuch. I'd have to dig up the details of that, but the core idea is to use Xapian "collapse keys" for more flexible handling of duplicates. > As for why it would be a security issue to ignore new messages with > duplicate message IDs, [...] Although perhaps not so colourfully, this has been extensively discussed on the mailing list, which is what lead to the functionality of indexing all files with the same message IDs. In short, new messages are not being ignored. > > My recommendation would be to split the Notmuch project into three > teams: Since there is a very small number of active developers (in some sense just me at the moment), I guess that won't happen. > (I think that all software projects should be run this way, so please > don't be offended.) I understand you probably didn't set out to become a notmuch contributor, but if you want your organizational suggestions to be taken seriously, I'm afraid that is a prerequisite. Of course contributions to all three of the areas you mentioned are welcome. > I wrote some Perl scripts a long time ago [...] > I am having to use Notmuch because of a third piece of software that > depends on it I can't speak to third party software dependencies, but you might investigate mu [1], or mairix [2] which might make design choices more to your liking. > It is somewhat perplexing to me that no one else has had my use case > before I guess one of the side effects of working on software like notmuch, which has several different interfaces (CLI, library, bindings), is that even after almost 15 years, it is impossible to predict all of the different ways people will try to use it. We try to accomodate new use cases as they arrive, but our priority is not breaking things for the existing users. This means being cautious about adding new features, given our limited resources for maintainance and support. [1]: https://www.djcbsoftware.nl/code/mu/ [2]: https://github.com/rc0/mairix _______________________________________________ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-leave@notmuchmail.org