Support for notmuch profiles

[robn]

I think mostly this means getting the maildir path from notmuch config item database.mail_root and then using that for path: queries, sync destination, etc. Which might mean changing/removing the cur/new/tmp setup, but maybe not if clients are really expecting it to look like that.

I'm not sure if its better or worse to explicitly set a profile name in mujmap config and pass that into Database::open_with_config, or just to require NOTMUCH_PROFILE to be set and the magic just happens. The latter is more notmuchy, the former is much more pleasant. But support first I think.

[elizagamedev]

I know some software depends on the cur/new/tmp setup. I thought that mutt was one of them, but maybe that's not the case with the notmuch backend.

I opted to keep limit it to the environment variable because it seemed like there were some weird edge cases that could come up if it were defined in mujmap.toml. For example, if two different profiles point to the same maildir, and mujmap is a child of that maildir, which profile should mujmap use on invocation? Since most people are likely going to be using mujmap in the pre/post-hooks of notmuch new, it seemed like the least surprising option was to just inherit the environment variables, so the pre/post hook behavior is always correct.

(Another option would be to allow it as a command-line argument like the various notmuch commands support.)

The database.mail_root stuff we're pretty much already doing. If mujmap is invoked with a profile that specifies a maildir that isn't a parent of the mujmap config files, the command will fail, since it means that the database we opened doesn't actually contain any of the mujmap mail files. I based this on lieer since it seemed like doing it this way would be the most difficult way for a user to mess up and accidentally cause damage to their database.

[robn]

I know some software depends on the cur/new/tmp setup. I thought that mutt was one of them, but maybe that's not the case with the notmuch backend.

I'm not sure, but it seems pretty necessary after some reading, so won't be removing that.

Since most people are likely going to be using mujmap in the pre/post-hooks of notmuch new, it seemed like the least surprising option was to just inherit the environment variables, so the pre/post hook behavior is always correct.

That's interesting, I hadn't thought about using it that way. Really depends on how you think about it hey!

I commit to not breaking any of this :)

The database.mail_root stuff we're pretty much already doing.

It's .. sort of. I'm working out a setup with separate notmuch indexes and maildirs for my different JMAP accounts, and the profile and split stuff and use of XDG dirs seems to arrange utlimately arrange for a database and maildir "side by side", which is confusing mujmap's db/maildir prefix check, and also the "all messages" query. Its a pretty modest patch to adjust it, and I have it working, just not cleaned up yet.

But I think database.mail_root allows the maildir to be outside of the database.path dir entirely, so mujmap enforcing that at least needs to go away.

My aim so far is to use the mail_root value if available, and if it returns the same as the database path (indicating an old or non-split config, unsure) then continue with the previous behaviour.

[elizagamedev]

It's .. sort of. I'm working out a setup with separate notmuch indexes and maildirs for my different JMAP accounts, and the profile and split stuff and use of XDG dirs seems to arrange utlimately arrange for a database and maildir "side by side", which is confusing mujmap's db/maildir prefix check, and also the "all messages" query. Its a pretty modest patch to adjust it, and I have it working, just not cleaned up yet.

Oh, I see, I misunderstood. That sounds good to me. 🙂 I'll await the PR.