Changing mu4e-{maildir,mu-home} from a context hook

[Ævar Arnfjörð Bjarmason]

I know this is documented not to work, it says you have to quit mu4e
and restart it.

Since this is rather tedious is there some open bug / things that need
to be worked on to just make mu4e do the equivalent of restarting
itself when you switch the context and it changes the index dir or
maildir in a context hook?

Is it more complex than just making sure the mu daemon is restarted
with a new --muhome option?

[Dirk-Jan C. Binnema]

That might work; mu4e-quit and restart. You could try to do that in a
context-switch (there are hooks and all), but I think it might get quite
confusing. Also, wouldn't be surprised if there are settings lingering
from the one instance to the next.

Contexts are the recommended mechanism here; I'm using it to handle a
bunch of different accounts, private and work, each with their own
context; is their something missing that makes that not work for you?

If you really want to use a separate --muhome, I'd recommend simply
opening another emacs instance.

Kind regards,
Dirk.

--
Dirk-Jan C. Binnema Helsinki, Finland
e:dj...@djcbsoftware.nl w:www.djcbsoftware.nl
pgp: D09C E664 897D 7D39 5047 A178 E96A C7A1 017D DA3C

[Ævar Arnfjörð Bjarmason]

On Thu, Nov 24, 2016 at 9:45 PM, Dirk-Jan C. Binnema
<dj...@djcbsoftware.nl> wrote:
>
> On Thursday Nov 24 2016, Ævar Arnfjörð Bjarmason wrote:
>
>> I know this is documented not to work, it says you have to quit mu4e
>> and restart it.
>>
>> Since this is rather tedious is there some open bug / things that need
>> to be worked on to just make mu4e do the equivalent of restarting
>> itself when you switch the context and it changes the index dir or
>> maildir in a context hook?
>>
>> Is it more complex than just making sure the mu daemon is restarted
>> with a new --muhome option?
>
> That might work; mu4e-quit and restart. You could try to do that in a
> context-switch (there are hooks and all), but I think it might get quite
> confusing. Also, wouldn't be surprised if there are settings lingering
> from the one instance to the next.
>
> Contexts are the recommended mechanism here; I'm using it to handle a
> bunch of different accounts, private and work, each with their own
> context; is their something missing that makes that not work for you?

Well, maybe I'm doing something very wrong but I have offlineimap sync
the two accounts to a different ~/Maildir/X subdirectory, and then I
have a ~/.mu/X for the index for each.

Works for me, and seemed like the intuitive thing to do, since the
accounts are separate, just slightly tedious to need to quit mu4e to
switch accounts.

> If you really want to use a separate --muhome, I'd recommend simply
> opening another emacs instance.

I still get a lot out of using the same emacs instance, i.e. all other
buffers are shared, shared kill ring etc.

[Joost Kremers]

On Fri, Nov 25 2016, Ævar Arnfjörð Bjarmason wrote:
> Well, maybe I'm doing something very wrong but I have
> offlineimap sync
> the two accounts to a different ~/Maildir/X subdirectory, and
> then I
> have a ~/.mu/X for the index for each.
>
> Works for me, and seemed like the intuitive thing to do, since
> the
> accounts are separate, just slightly tedious to need to quit
> mu4e to
> switch accounts.

Yes. I don't think there's any reason to do what you do, though. I
have three email account that offlineimap syncs to three different
directories under ~/Mail/. It's just that I have mu index the
whole lot in one go. Separating the accounts is easy if you use
contexts, and you can limit searches by maildir, if you want to. I
have different bookmarks for the inboxes of the three accounts,
for example. (Though most of the time I just use a bookmark that
gives me a unified inbox.)

Having a single index for all accounts does mean that your
contacts aren't separated by account, and searching for messages
may return messages from different accounts if you don't specify a
maildir in the search (which may not always be practical, I
admit). But unless you're really strict about it, I don't think
that's really a problem.

Unless of course you have a use case that I'm overlooking.


--
Joost Kremers
Life has its moments

[Dirk-Jan C. Binnema]

Hi Ævar

On Friday Nov 25 2016, Ævar Arnfjörð Bjarmason wrote:

>> Contexts are the recommended mechanism here; I'm using it to handle a
>> bunch of different accounts, private and work, each with their own
>> context; is their something missing that makes that not work for you?
>
> Well, maybe I'm doing something very wrong but I have offlineimap sync
> the two accounts to a different ~/Maildir/X subdirectory, and then I
> have a ~/.mu/X for the index for each.
>
> Works for me, and seemed like the intuitive thing to do, since the
> accounts are separate, just slightly tedious to need to quit mu4e to
> switch accounts.

Well, there's nothing /wrong/ of course - but at least I'm using a bunch
of accounts (offlineimap and fetchmail), that dump their stuff in their
own subdir under ~/Maildir -- similar to what Joost describes; and that
seems to work quite fine for me.

I occasionally find it useful to mix accounts, so this works well with
that.

>> If you really want to use a separate --muhome, I'd recommend simply
>> opening another emacs instance.
>
> I still get a lot out of using the same emacs instance, i.e. all other
> buffers are shared, shared kill ring etc.

So you can share accounts; or you can separate accounts; but it seems
you want something in between. I guess you can write a
'switch-account' for that quits/starts; shouldn't be too hard (but ymmv,
as mentioned before).

[Stig Brautaset]

I am not sure if my setup works for you, but I have:

- two IMAP accounts, and mbsync set up to mirror to
~/Maildir/Private and
~/Maildir/Work
- mu indexing ~/Maildir (it handles subdirectories just fine)
- Using contexts to set different mu4e-get-mail-command,
mu4e-maildir-shortcuts, and mu4e-bookmarks

So that when I'm in the Private context mbsync is invoked with
'mbsync
private' and in work context it's invoked with 'mbsync work'. I am
aware that
it is documented not to work, but it seems to for me on the
as-yet-to-be-released dev version. I do not run the daemon, so
have to press
"U" when getting new mail, which might be why it works for me.

At any rate, I think just setting the shortcuts and bookmarks
might suffice,
if you're using the daemon, as the keystrokes would be the same.
The =:vars=
section of my private context looks like this:

#+BEGIN_SRC emacs-lisp
:vars '((user-mail-address . "st...@brautaset.org")

(mu4e-sent-folder . "/Private/sent")
(mu4e-drafts-folder . "/Private/drafts")
(mu4e-trash-folder . "/Private/trash")
(mu4e-refile-folder . "/Private/Archive")

(mu4e-get-mail-command . "mbsync icloud")

;; Quickly jump to maildir based on context
(mu4e-maildir-shortcuts . (("/Private/INBOX" . ?i)
("/Private/Lists" . ?l)
("/Private/archive" . ?a)))

(mu4e-bookmarks . (("flag:unread AND NOT flag:trashed
AND maildir:/Private/INBOX AND NOT maildir:/Private/*"
"Unread Messages" ?u)
("flag:unread AND NOT flag:trashed
AND maildir:/Private/Lists" "Unread
List Messages" ?l)
("date:today..now AND
maildir:/Private/*" "Today's
messages" ?t)
("date:7d..now AND
maildir:/Private/*" "Last 7 days"
?7)))


(mu4e-sent-messages-behavior . sent)
(mu4e-compose-signature . nil)))
#+END_SRC

Hope this helps!

Stig

[Ævar Arnfjörð Bjarmason]

Yeah makes sense that I could just use maildir: search filter instead
of doing this.

Because of this setup I submitted a related pull request just now:
https://github.com/djcb/mu/pull/1031

I also thought I'd send a note / question about this because I've
found another use-case for this that's quite neat.

I now have a large maildir/index that I almost never look at, but want
to keep around for reference. I by splitting out the mu index I can
keep that data on a slower spinning disk I may not even have mounted
all the time instead of on my local SSD.

I was pondering taking this a step further and even just mounting the
maildir & xapian database as read-only, I got as far as this
monkeypatch:

diff --git a/lib/mu-runtime.c b/lib/mu-runtime.c
index a8e78dd4..3da7e79a 100644
--- a/lib/mu-runtime.c
+++ b/lib/mu-runtime.c
@@ -94,6 +94,6 @@ mu_runtime_init (const char* muhome_arg, const char *name)
if (!mu_util_create_dir_maybe (muhome, 0700, TRUE)) {
- g_printerr ("mu: invalid mu homedir specified;"
- " use --muhome=<dir>\n");
- runtime_free ();
- return FALSE;
+ /*g_printerr ("mu: invalid mu homedir specified;"
+ " use --muhome=<dir>\n");*/
+/* runtime_free ();
+ return FALSE;*/
}
diff --git a/lib/mu-util.c b/lib/mu-util.c
index cac5a4a9..a394349b 100644
--- a/lib/mu-util.c
+++ b/lib/mu-util.c
@@ -206,3 +206,3 @@ mu_util_guess_mu_homedir (void)

- if (hdir1 && mu_util_check_dir (hdir1, TRUE, FALSE))
+ if (hdir1 && mu_util_check_dir (hdir1, FALSE, FALSE))
return g_strdup (hdir1);

Following these instructions to get a ro filesystem:
http://unix.stackexchange.com/questions/27449/mount-a-filesystem-read-only-and-redirect-writes-to-ram

That along with this hack:

$ file /tmp/imgmnt/exchange/log/mu.log
/tmp/imgmnt/exchange/log/mu.log: symbolic link to /tmp/mu.log

Makes e.g. mu find work from the command line, you can search a
read-only database, it issues a warning about being unable to create
the cache dir though.

mu4e though keeps erroring out with "db locked by another process". I
haven't traced down why that's happening.

Is there any reason in principle for why the xapian database would
need to be mounted read-write for just browsing the e-mail / doing
searches / never changing any flags?

[Joost Kremers]

On Fri, Feb 17 2017, Ævar Arnfjörð Bjarmason wrote:
> I now have a large maildir/index that I almost never look at,
> but want
> to keep around for reference. I by splitting out the mu index I
> can
> keep that data on a slower spinning disk I may not even have
> mounted
> all the time instead of on my local SSD.

Are you aware of the .noupdate cookie? Put a file called
'.noupdate' in a directory and mu won't update it during
reindexing (unless you specify --rebuild). So the mail there is
still accessible, but it's assumed no changes are being made.

[Ævar Arnfjörð Bjarmason]

Yeah I know, but that's an indexing timesaving optimization. The
problem I'm solving is that e.g. one index of mail that'll never
change again is 10GB with a 60GB maildir or whatever, and my
maildir/index that changes is say 5GB with a 30GB maildir.

So the setup I described in my initial post allows you to have that
60GB maildir browseable & searchable by mu without keeping it on your
main / partition.

And what I'm wondering in my previous post here is whether I couldn't
also just mount the old maildir/xapian index read-only on the fs
level. That seems to almost work.

I'd like to make it read-only just for my own peace of mind (knowing
I'll never need to worry about e.g. forgetting what account I'm on and
D-ing a message), but I could see it being a useful mode to work in
one some filesystems, e.g. NFS could cache things like that much more
aggressively, presumably.

> --
> Joost Kremers
> Life has its moments
>

> --
> You received this message because you are subscribed to the Google Groups
> "mu-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mu-discuss+...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Eduardo Mercovich]

Hi Ævar.

>>> I now have a large maildir/index that I almost never look at,

>>> but want to keep around for reference. [...]

>> Are you aware of the .noupdate cookie? [...]

> Yeah I know, but that's an indexing timesaving optimization. The
> problem I'm solving is that e.g. one index of mail that'll never
> change again is 10GB with a 60GB maildir or whatever, and my
> maildir/index that changes is say 5GB with a 30GB maildir.

Just for the records, your case is quite similar to mine and I
have the same working setup that Joost mentioned, working
perfectly.

I totally undertand that you're looking for a more profound
optimization, but as always, just be sure that the costs/benefits
balance doesn't go out of range.

OTOH, if it's for the pleasure of hacking, the great asymptote is
always there to be walked. ;)

Best regards...

--
Eduardo Mercovich

Donde se cruzan tus talentos
con las necesidades del mundo,
ahí está tu vocación.
(Anónimo)