Fails when root is Maildir

[darkfeline]

If mu4e-maildir is itself a Maildir, mu4e-maildirs-extension fails.

Debugger entered--Lisp error: (wrong-type-argument wholenump -2)
  make-string(-2 32)
  mu4e-maildirs-extension-new-maildir("/")
  mapcar(mu4e-maildirs-extension-new-maildir ("/"))
  mu4e-maildirs-extension-load-maildirs()
  mu4e-maildirs-extension-update()
  mu4e-maildirs-extension-main-view-handler()
  run-hooks(change-major-mode-after-body-hook special-mode-hook mu4e-main-mode-hook)
  apply(run-hooks (change-major-mode-after-body-hook special-mode-hook mu4e-main-mode-hook))
  run-mode-hooks(mu4e-main-mode-hook)
  mu4e-main-mode()
  mu4e~main-view-real(nil nil)
  mu4e~main-view()
  mu4e~start(mu4e~main-view)
  mu4e(nil)
  call-interactively(mu4e nil nil)
  command-execute(mu4e)

[jpfairbanks]

1. Does "is a mailbox" mean "is a directory containing subdirectories: new, cur, tmp"?
2. If root is a maildir, does that indicate improper initialization of the Maildir directory?

I set things up with OfflineIMAP, but have also used gnus and mu4e with this maildir. I would not be surprised if things got messed up by conflicting settings or initializations.

[darkfeline]

1. Yes, a Maildir is defined by containing those three subdirectories.
2. I don't think so.

For reference, I am using mbsync (isync), but the particular tool shouldn't matter. The bug happens when

mu4e-maildir/
    cur/
    new/
    tmp/
    Gmail/
        cur/
        new/
        tmp/
    ...

The key is when mu4e-maildir is a Maildir, you can see the "/" getting passed through in the stack trace.

[jpfairbanks]

So is there any reason for the root to also be a maildir? I am thinking that a workaround is to remove the cur, new, tmp directories from mu4e-maildir/. But I don't want to do that if there is a good reason for the root to be a maildir.

[darkfeline]

Firstly, because it's misleading that this package breaks if mu4e-maildirs is, god forbid, actually set to a Maildir directory.

Secondly, because if a user only has one Maildir, it seems odd to force the user to put that Maildir in a separate directory (e.g., if I have a maildir ~/Maildir, I have to move it to ~/mail/Maildir, symlink ~/Maildir to ~/mail/Maildir, then point mu4e-maildirs at ~/mail, for no gain).

Thirdly, because nesting Maildirs is a perfectly valid way of managing multiple Maildirs or folders.

[agpchil]

Sorry for the late reply!

This extension expects a directory for each account inside mu4e-maildir. So you should have something like this:

~/Mail/myaccount
~/Mail/myaccount/cur
~/Mail/myaccount/new
~/Mail/myaccount/tmp
~/Mail/myaccount/Gmail
~/Mail/myaccount/Gmail/cur
~/Mail/myaccount/Gmail/new
~/Mail/myaccount/Gmail/tmp
...

And set mu4e-maildir to ~/Mail

I've not tested this with/alongside GNUS but I think it should work. Maybe you'll need to update GNUS config to point to ~/Mail/myaccount instead?

[runswithd6s]

I'm also running in to this. My debug info was also added to the mu4e layer issue with spacemacs. I have only one account, and expect to use ~/Maildir for it. Note, this is how someone might use a server that stores mail received by an email server into a user's home directory -- like mine! :grin: Or, alternatively, when using offlineimap or fetchmail + procmail.

[agpchil]

As I said in the previous comment, this extension expects a directory structure to work. You should be able to configure offlineimap or other software to store your mail in specific directory.

Feel free to send a PR if you implement this feature!

[wilhelmy]

I'm running into the same issue. This is typically how subdirectories to Maildir are implemented (Maildir++), so if you're e.g. reading mail directly from ~/Maildir where your MTA drops it off, it breaks. Even if you don't intend your extension to be used this way, it shouldn't raise a cryptic error when it fails to handle a Maildir in my opinion.

As far as I've investigated, (mu4e-maildirs-extension-parse "/") returns nil, mu4e-maildirs-extension-new-maildir invokes (1- (length nil)) yielding -1 and uses this as the level, which is then later used in a multiplication.

[gpcf]

I can also confirm this bug. I installed maildirs-extensions today from melpa and mu4e wouldn't start due to exactly this same issue. It went away after removing /cur, /new and /tmp from my root maildir.