Replace mu4e multiple accounts with contexts

[darkfeline]

mu4e 0.9.16 now comes with a native contexts feature that completely
replaces the old hack for multiple accounts.

[TheBB]

This is the thing though… how widespread is mu4e 0.9.16? With MELPA we can reasonably demand that everyone have the latest version of everything, but here not.

[nixmaniack]

@TheBB Indeed an important point. I don't think I'm going to update mu4e sooner even though I use develop. So this would probably break things for me if I'm using this code.

[AlejandroCatalina]

I'm also using multiple-accounts instead of contexts and that would break my config. I don't know how safe is for us to update this. It's indeed a good feature, but I'm afraid a lot of people will be like us, using the old system.

[darkfeline]

I am okay with waiting until some predetermined milestone (Debian? Ubuntu?) before merging this. This does two things:

1. Remove multiple accounts hack.
2. Update documentation.

So it's not necessary to use contexts and can be merged at leisure.

[kostajh]

Just to note -- I was (and still am) using the multiple accounts hack from Spacemacs, and updated to 0.9.16. Nothing is broken, everything works as before. The contexts feature is just much nicer and deeply integrated into mu4e.

[zakkak]

What about supporting both ways for now and adding a note that multiple-accounts are deprecated, and later, when mu4e 0.9.16 is mature enough to be available in most repositories, drop the backwards compatibility.

[darkfeline]

Here are links to the packages for Debian and Ubuntu:

https://packages.debian.org/sid/main/mu4e
http://packages.ubuntu.com/search?keywords=mu4e

They are on 0.9.12 as of this post. It really makes me appreciate using a bleeding edge distribution...

I would have suggested keeping this open until 0.9.16 hits either repository, but it looks like we'd have to wait another decade. In the meantime, a PR that documents mu4e's contexts feature is probably needed.

[zakkak]

IMHO duplicating documentation does not seem a good idea. Maybe adding a link to the corresponding mu4e documentation about the contexts would be better until they get supported by the layer.

In the meantime, @darkfeline what do you think about supporting both with an if statement that would first check for the presence of mu4e-contexts and if absent check for the mu4e-account-alist (which by the way does not comply to the naming convensions).

This way we do not break any user's workflow while moving towards the bleeding edge ;)

[darkfeline]

check for the mu4e-account-alist (which by the way does not comply to the naming convensions).

Variables follow these conventions:

• spacemacs-xxx is a variable

Last I checked, the convention for naming layer variables is <layer-name>-<variable-name>. The layer name is mu4e and the variable name is account-alist. Am I wrong?

what do you think about supporting both with an if statement that would first check for the presence of mu4e-contexts and if absent check for the mu4e-account-alist

I don't think that's necessary. Contexts and the account-alist hack can exist simultaneously. You can even use both at once, although that's pointless.

I am thinking:

For now, update the docs, leave the hack.

For later, remove the hack, update the docs.

(I am sort of glad so many people are happily using my hack though.)

[zakkak]

Last I checked, the convention for naming layer variables is <layer-name>-<variable-name>. The layer name is mu4e and the variable name is account-alist. Am I wrong?

I am fairly new here so probably I am the one being wrong. From the documentation I got the impression that every variable should be of the form spacemacs-xxx.

Anyway, having variables named mu4e-xxx seems a bad practice to me, since those might conflict with mu4e's variables at some point.

[darkfeline]

Update documentation in the meantime: #4895

Let this PR sit until such time that mu 0.9.16 becomes commonplace.

[kepi]

I'm not sure if it is good idea but wouldn't it be better to create new layer like mu4e-ng so those with new mu4e could benefit from this great future right now?

Or - IMHO cleaner approach - have switch in layer configuration which will load different configuration if user set something like ...mu4e-0916 to true?

[d12frosted]

I would like to see this PR on develop branch.

[jhenahan]

Using 0.9.16, and defining context as described in the mu4e manual and in this commit, I can't seem to get mu4e to actually register the contexts. Any guidance? I've tried putting it in user-config and user-init, but no dice. Redacted code here: http://lpaste.net/4182833052885450752

EDIT: Looks like I had to wrap it in (with-eval-after-load 'mu4e). Is there a good way to avoid this extra step?

[d12frosted]

Any updates on this particular issue?

[darkfeline]

mu 0.9.16 with support for contexts is in Debian stretch (testing) and sid (unstable). Current stable (jessie) does not have it.

If this is good enough for Spacemacs to assume users have it, I can update the PR and get it merged. @syl20bnr

[d12frosted]

Oh welp, what about other distributions? I bet in Arch 0.9.16 is available 😸

P. S. this version is available on OS X via brew.

[TheBB]

Can we check the mu version at runtime and conditionally enable this feature? Or, since we obviously can, is it practical?

[nixmaniack]

It would make sense to enable it conditionally and also make it customizable for users who don't want to use it and keep using old multiple-account hack.
If I'm the only one here using old account hack, then it's time for me to look into contexts and upgrade sooner!

[darkfeline]

If the people who are using the multiple accounts hack are happy with it and don't/can't use mu4e contexts for some reason, I guess we can keep it? But the fact is, it's hacky, and it is completely superceded by the new upstream feature. I don't think Spacemacs should maintain a half-assed feature backport for an upstream package.

[syl20bnr]

Thank you ! 👍

I prefer to remove the code and tell people to update their tools and used the intended feature.

Cherry-picked into develop branch, you can safely delete your branch.