Some time ago I noticed the cooperative lock file management wasn't
working as I remember. I forget what exactly I was thinking, but
basically I've poked at the code until it seems to work better.
+mu4e-lock-available seems like a potential entry-point to the mu-lock
functionality, e.g. on startup check if another Emacs process has mu4e
active, and so it might as well be turned into an autoload.
Thanks to some combination of ignorance and obstinance, mu4e has thrown
compatibility to the wind and completely ignored the exitance of
define-obsolete-function-alias. Coupled with the inconsistent/partial
function renaming, this has made the mu4e 1.6⟶1.8 change particularly
annoying to deal with.
By suffering the pain of doing the mu4e author's work for them, we can
use defalias to give backwards compatibility a good shot for about 60
functions. Some mu4e~x functions are now mu4e--x, others are unchanged,
and then you've got a few odd changes like mu4e~proc -> mu4e--server and
mu4e-search-rerun. The form of message :from entries has also changed,
and a new (mu4e) entrypoint added supplanting mu4e~start.
Fix: #6511Close: #6549
Co-authored-by: Rahguzar <aikrahguzar@gmail.com>
On mac process args aren't defined, but comm is. Since comm also works
on Linux, we now check for that instead, accounting for a potential
capitalisation difference.
On some OS implementations (e.g. BSD uses kqueue),
`file-notify-add-watch' might not create the file if it doesn't exist.
This patch fixes that error. Arguably, emacs lisp should ensure the same
behaviour exists across each implementation.
