[mu4e bug] error in process filter: Symbol’s function definition is void: mu4e-view

[niklas]

Describe the bug When I browse my emails and open one to view it, I expect it to be opened, its content shown. Instead, Emacs gives me an error:

error in process filter: mu4e~headers-view-handler: Symbol’s function definition is void: mu4e-view
error in process filter: Symbol’s function definition is void: mu4e-view

To Reproduce Happens with every message I open.

Environment Arch Linux with mu 1.8.1-1 and emacs-git 28.1.50 (both from AUR). I uninstalled and reinstalled both to make sure the install is clean.

Checklist

• [ ] you are running vanilla emacs (i.e. without Doom, Evil, Spacemacs etc.) (otherwise, please try to reproduce without those Sorry, I am using Spacemacs and still too noob to set up a vanilla emacs myself.
• [x] you are running mu4e without any third-party extensions (otherwise, please try to reproduce without those)
• [x] you are running either the latest 1.6.x release, or a 1.7.x development release (otherwise, please upgrade).

As far as I see, the error is raised here: https://github.com/djcb/mu/blob/master/mu4e/mu4e-headers.el#L725 Which is weird to me, because the NEWS.org for 1.8 says the mu4e-view was removed in favor of gnus (I dunno what that is).

[djcb]

It seems no one else got this error, so it's likely some local setup error. My guess would be that there's some older version lying around (or .elc). Maybe search your file system for older versions. But who knows.

Please try with emacs -q, add to your load-path (with something like

(add-to-list 'load-path " /usr/local/share/emacs/site-lisp/mu4e/")
(require 'mu4e)

and then M-x mu4e.

[Phundrak]

I get the same issue as Niklas here.

Environment

Arch Linux with mu 1.8.1-1 from the AUR, and Emacs 29.0.50.

Checklist

• [X] you are running vanilla emacs (i.e. without Doom, Evil, Spacemacs etc.)
• [X] you are running mu4e without any third-party extensions (otherwise, please try to reproduce without those)
• [X] you are running either the latest 1.6.x release, or a 1.7.x development release (otherwise, please upgrade).

The issue goes away if I manually (require 'mu4e-view). Weirdly enough, it doesn’t happen with emacs -q, though I do need to (require 'mu4e) before.

[niklas]

I deleted all .elc files system wide. First boot of emacs was slow (obviously), opening a message in mu4e worked. Quit, tried again: back to the above error.

Phundrak's hack works for me.

[djcb]

Ah yeah, need to add the (require 'mu4e); I've updated the example.

(require 'mu4e-view) works but it should happen automatically; not sure why it doesn't. Perhaps something in the way Arch packages it?

[djcb]

So my recommendation would to be to take this issue to the Arch packagers, as this seems to be an Arch-specific issue, apparently something with byte-compilation. This code has been used by many people for months, so there must be something special with the way Arch does it.

Could this still be some mu/mu4e issue? Sure, perhaps it's breaking some assumption that the Arch packaging depends on. But hopefully they're able to tell us.

[prosoitos]

Also using mu 1.8.1-1 from the AUR and having a similar issue but for another function:

error in process filter: mu4e--server-filter: Symbol’s function definition is void: nil
error in process filter: Symbol’s function definition is void: nil

Since mu4e--server-filter is in mu4e-server.el, I tried:

(require 'mu4e-server)

But that didn't help.

[djcb]

Yeah, that seems like another case of the same problem. I suspect something related to either byte-compilation or native compilation

As a hack, you could try something in your config, to force-load everything:

(seq-do (lambda (file) (load-file file))
    (directory-files "/usr/local/share/emacs/site-lisp/mu4e" t ".*\\.el$"))

(and change the path as needed to point to the path where the mu4e files are installed)

[prosoitos]

Thanks!

[milouse]

I’m currently on Archlinux, with Emacs 28.1-7 (default package, without native compilation) and mu 1.8.1-1 (byte compiled) and don’t have any trouble with the following line in my Emacs configuration:

(autoload 'mu4e "/usr/share/emacs/site-lisp/mu4e/mu4e"
 "Start mu4e daemon and show its main window." t)

No need for specific add-to-list 'load-path or require statement. Thus I don’t think it’s a packaging issue (the Archlinux package just do a meson build/meson install), but maybe more a specific Spacemacs/Emacs 29.x issue? Or native comp issue?

@niklas @Phundrak can you check if your Emacs package is built with support for native comp or not? What I can imagine, is that the mu4e aur package currently just "byte compile", what is fine with the default/regular archlinux Emacs package. But you are using specific Emacs package and maybe, if they expect other things to be native-compiled, they won’t work well with byte compiled file? (just a guess here).

Said otherwise: can you check if you still have the problem with the regular Archlinux Emacs package? If no, the problem is with your specific Emacs version (spacemacs, devel, native comp…).

[theophilusx]

I'm running with Emacs 28 and 29 on Ubuntu and Fedora with no problems (both with and without spacemacs).

All the reported problems with issues over require have been on Arch or Arch based distributions, so I also suspect it is Arch specific.

I did not have to modify my install/startup from the previous version (i.e. no need to add any additional require statements etc).

I am not using native compile. I do build directly from a clone of the git repo for mu.

[Phundrak]

@niklas @Phundrak can you check if your Emacs package is built with support for native comp or not?

This might be it, I do indeed have native-comp enabled by default. I tried cleaning my ELN cache and even upgrading Emacs to force it to regenerate the ELNs, but still no luck. I’ll try recompiling Emacs without native-comp later to test if it is indeed the source of the bug.

-- Lucien “Phundrak” Cartier-Tilet https://phundrak.com (Français) https://phundrak.com/en (English) Sent from GNU/Emacs

[prosoitos]

The problem I reported above is with the regular Arch Emacs package

[prosoitos]

@djcb: your hacky fix of force loading everything worked, so until this gets sorted in a cleaner fashion, I'll go with that. Thanks again!

[prosoitos]

Btw, here is the answer from the mu package maintainer in the AUR

[djcb]

@prosoitos: thanks for the link!

[Phundrak]

I just installed a native-comp free Emacs, and the issue is still here, so native-comp doesn’t seem to be at fault here.

[prosoitos]

I am now wondering whether my problem is related to this issue or actually a totally different one.

After force-reading all mu4e files (following @djcb's advice), I don't get the error I used to get (

error in process filter: mu4e--server-filter: Symbol’s function definition is void: nil
error in process filter: Symbol’s function definition is void: nil

), but I am now getting the error:

funcall: Symbol’s function definition is void: nil

And that new error seems to have to do with mu4e--server-filter.

Here is the debugger info:

Debugger entered--Lisp error: (void-function nil)
  nil((:info index :status running :checked 11468 :updated 0 :cleaned-up 0))
  funcall(nil (:info index :status running :checked 11468 :updated 0 :cleaned-up 0))
  (cond ((plist-get sexp :headers) (funcall mu4e-headers-append-func (plist-get sexp :headers))) ((plist-get sexp :found) (funcall mu4e-found-func (plist-get sexp :found))) ((plist-get sexp :view) (funcall mu4e-view-func (plist-get sexp :view))) ((plist-get sexp :erase) (funcall mu4e-erase-func)) ((plist-get sexp :sent) (funcall mu4e-sent-func (plist-get sexp :docid) (plist-get sexp :path))) ((plist-get sexp :pong) (setq mu4e--server-props (plist-get sexp :props)) (funcall mu4e-pong-func sexp)) ((plist-member sexp :contacts) (funcall mu4e-contacts-func (plist-get sexp :contacts) (plist-get sexp :tstamp))) ((plist-get sexp :update) (funcall mu4e-update-func (plist-get sexp :update) (plist-get sexp :move) (plist-get sexp :maybe-view))) ((plist-get sexp :remove) (funcall mu4e-remove-func (plist-get sexp :remove))) ((plist-get sexp :compose) (funcall mu4e-compose-func (plist-get sexp :compose) (plist-get sexp :original) (plist-get sexp :include))) ((plist-get sexp :info) (funcall mu4e-info-func sexp)) ((plist-get sexp :error) (funcall mu4e-error-func (plist-get sexp :error) (plist-get sexp :message))) (t (mu4e-message "Unexpected data from server [%S]" sexp)))
  (while sexp (mu4e-log 'from-server "%s" sexp) (cond ((plist-get sexp :headers) (funcall mu4e-headers-append-func (plist-get sexp :headers))) ((plist-get sexp :found) (funcall mu4e-found-func (plist-get sexp :found))) ((plist-get sexp :view) (funcall mu4e-view-func (plist-get sexp :view))) ((plist-get sexp :erase) (funcall mu4e-erase-func)) ((plist-get sexp :sent) (funcall mu4e-sent-func (plist-get sexp :docid) (plist-get sexp :path))) ((plist-get sexp :pong) (setq mu4e--server-props (plist-get sexp :props)) (funcall mu4e-pong-func sexp)) ((plist-member sexp :contacts) (funcall mu4e-contacts-func (plist-get sexp :contacts) (plist-get sexp :tstamp))) ((plist-get sexp :update) (funcall mu4e-update-func (plist-get sexp :update) (plist-get sexp :move) (plist-get sexp :maybe-view))) ((plist-get sexp :remove) (funcall mu4e-remove-func (plist-get sexp :remove))) ((plist-get sexp :compose) (funcall mu4e-compose-func (plist-get sexp :compose) (plist-get sexp :original) (plist-get sexp :include))) ((plist-get sexp :info) (funcall mu4e-info-func sexp)) ((plist-get sexp :error) (funcall mu4e-error-func (plist-get sexp :error) (plist-get sexp :message))) (t (mu4e-message "Unexpected data from server [%S]" sexp))) (setq sexp (mu4e--server-eat-sexp-from-buf)))
  (let ((inhibit-quit nil)) (while sexp (mu4e-log 'from-server "%s" sexp) (cond ((plist-get sexp :headers) (funcall mu4e-headers-append-func (plist-get sexp :headers))) ((plist-get sexp :found) (funcall mu4e-found-func (plist-get sexp :found))) ((plist-get sexp :view) (funcall mu4e-view-func (plist-get sexp :view))) ((plist-get sexp :erase) (funcall mu4e-erase-func)) ((plist-get sexp :sent) (funcall mu4e-sent-func (plist-get sexp :docid) (plist-get sexp :path))) ((plist-get sexp :pong) (setq mu4e--server-props (plist-get sexp :props)) (funcall mu4e-pong-func sexp)) ((plist-member sexp :contacts) (funcall mu4e-contacts-func (plist-get sexp :contacts) (plist-get sexp :tstamp))) ((plist-get sexp :update) (funcall mu4e-update-func (plist-get sexp :update) (plist-get sexp :move) (plist-get sexp :maybe-view))) ((plist-get sexp :remove) (funcall mu4e-remove-func (plist-get sexp :remove))) ((plist-get sexp :compose) (funcall mu4e-compose-func (plist-get sexp :compose) (plist-get sexp :original) (plist-get sexp :include))) ((plist-get sexp :info) (funcall mu4e-info-func sexp)) ((plist-get sexp :error) (funcall mu4e-error-func (plist-get sexp :error) (plist-get sexp :message))) (t (mu4e-message "Unexpected data from server [%S]" sexp))) (setq sexp (mu4e--server-eat-sexp-from-buf))))
  (condition-case nil (let ((inhibit-quit nil)) (while sexp (mu4e-log 'from-server "%s" sexp) (cond ((plist-get sexp :headers) (funcall mu4e-headers-append-func (plist-get sexp :headers))) ((plist-get sexp :found) (funcall mu4e-found-func (plist-get sexp :found))) ((plist-get sexp :view) (funcall mu4e-view-func (plist-get sexp :view))) ((plist-get sexp :erase) (funcall mu4e-erase-func)) ((plist-get sexp :sent) (funcall mu4e-sent-func (plist-get sexp :docid) (plist-get sexp :path))) ((plist-get sexp :pong) (setq mu4e--server-props (plist-get sexp :props)) (funcall mu4e-pong-func sexp)) ((plist-member sexp :contacts) (funcall mu4e-contacts-func (plist-get sexp :contacts) (plist-get sexp :tstamp))) ((plist-get sexp :update) (funcall mu4e-update-func (plist-get sexp :update) (plist-get sexp :move) (plist-get sexp :maybe-view))) ((plist-get sexp :remove) (funcall mu4e-remove-func (plist-get sexp :remove))) ((plist-get sexp :compose) (funcall mu4e-compose-func (plist-get sexp :compose) (plist-get sexp :original) (plist-get sexp :include))) ((plist-get sexp :info) (funcall mu4e-info-func sexp)) ((plist-get sexp :error) (funcall mu4e-error-func (plist-get sexp :error) (plist-get sexp :message))) (t (mu4e-message "Unexpected data from server [%S]" sexp))) (setq sexp (mu4e--server-eat-sexp-from-buf)))) (quit (setq quit-flag t) (eval '(ignore nil))))
  (let ((sexp (mu4e--server-eat-sexp-from-buf))) (condition-case nil (let ((inhibit-quit nil)) (while sexp (mu4e-log 'from-server "%s" sexp) (cond ((plist-get sexp :headers) (funcall mu4e-headers-append-func (plist-get sexp :headers))) ((plist-get sexp :found) (funcall mu4e-found-func (plist-get sexp :found))) ((plist-get sexp :view) (funcall mu4e-view-func (plist-get sexp :view))) ((plist-get sexp :erase) (funcall mu4e-erase-func)) ((plist-get sexp :sent) (funcall mu4e-sent-func (plist-get sexp :docid) (plist-get sexp :path))) ((plist-get sexp :pong) (setq mu4e--server-props (plist-get sexp :props)) (funcall mu4e-pong-func sexp)) ((plist-member sexp :contacts) (funcall mu4e-contacts-func (plist-get sexp :contacts) (plist-get sexp :tstamp))) ((plist-get sexp :update) (funcall mu4e-update-func (plist-get sexp :update) (plist-get sexp :move) (plist-get sexp :maybe-view))) ((plist-get sexp :remove) (funcall mu4e-remove-func (plist-get sexp :remove))) ((plist-get sexp :compose) (funcall mu4e-compose-func (plist-get sexp :compose) (plist-get sexp :original) (plist-get sexp :include))) ((plist-get sexp :info) (funcall mu4e-info-func sexp)) ((plist-get sexp :error) (funcall mu4e-error-func (plist-get sexp :error) (plist-get sexp :message))) (t (mu4e-message "Unexpected data from server [%S]" sexp))) (setq sexp (mu4e--server-eat-sexp-from-buf)))) (quit (setq quit-flag t) (eval '(ignore nil)))))
  mu4e--server-filter(#<process *mu4e-server*> "\37646\377(:info index :status running :checked 11468 :u...")

Any thought??

Thank you!

Note: happy to open a new issue if this were more suitable than posting here.

[djcb]

I think it's all the same issue, so it's fine adding more info here. From the earlier comments, so far we learned that:

1. some (but not all) Arch users see this after upgrading; other users do not seem to experience this problem
2. removing the elc files made it work.... once. Presumably because the elc files get re-generated.

I tried to follow what the https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=mu does, installing with DESTDIR=/tmp/bla meson install -C build.

Then starting with emacs -q:

(add-to-list 'load-path "/tmp/bla/usr/local/share/emacs/site-lisp/mu4e")
(require 'mu4e)

and then M-x mu4e works just fine. So I'm out of ideas now...

[mrsch]

I was getting the same error and did some debugging.

It seems like the handlers are not initialized if you don't call mu4e before running other functions like mu4e-update-mail-and-index

Initializing the handlers manually after loading fixed the issue for me:

(add-to-list 'load-path "/usr/local/share/emacs/site-lisp/mu4e")
(require 'mu4e)
(mu4e--init-handlers)

[milouse]

Naïve question there: every ones having the bug, how do you "start" mu4e? I mean what do you do before getting the bug? Open emacs and M-x mu4e? Or do you have some lisp code in your config files which try to do something (like updating your mail folders?). Do you use a custom Emacs Dashboard, which try to display some information about your mails ?

[prosoitos]

Ah. I think that mrsch and milouse are on to something! 🙂

I have an emacs-server running all the time and I launch mu4e in a new emacsclient through i3-wm (I have a kbd that launches emacsclient -c and then emacsclient -e "(mu4e)" thanks to the exec function of i3).

It is indeed possible that the reason I am having that error message (that nobody else gets) has to do with my way to launch mu4e (note that I have done that for a long time and never had issues with previous versions).

I will try mrsch's fix and see whether it works for me. If this fails, I will also try to launch mu4e with M-x mu4e (but I like my workflow as it allows me to have my emails in a workspace distinct from my "normal" Emacs workspace. So I hope that the former attempt will work!).

[prosoitos]

Oh and I also sync my emails and update the mu4e index every 5 min with a systemd timer which runs the following zsh script:

#!/bin/zsh

/usr/bin/mbsync -Va &> /home/marie/systemd_log/mail_sync.log
/usr/bin/emacsclient -e '(mu4e-update-index)' &> /home/marie/systemd_log/mu_index.log

Maybe I get the error message every time the script runs... (although, I don't get the error message in the systemd timer logs that I create at each run).

(And that script of course runs whether or not my emacsclient with mu4e exists. It allows me to have everything up to date whenever I launch that emacsclient to check emails quickly before killing it again).

[prosoitos]

It seems that I was having the same problem as mrsch since I was running mu4e-update-index through systemd timers (so many times before I would ever run mu4e).

His solution to initialize the handlers manually by adding (mu4e--init-handlers) in the init file seems to have also fixed the issue for me.

Thank you so much mrsch!!!

[prosoitos]

@mrsch, may I ask you how you figured that out? (and thank you again so much for your fix!!!)

[djcb]

@milouse: good question!

Great there's a solution for some problem, but... before doing anything with mu4e, you should invoke it first (and it can be done in the background)., so everything is set up correctly. I'd avoid mu4e--init-handlers which is an internal function, even if it avoids the immediate errors, but doesn't go through the normal setup. So: (mu4e 'background) should do the trick.

I'm not yet convinced this describes all the problems see in this ticket... and why only (?) Arch users seems to be affected.

[RidaAyed]

I was getting the same error and did some debugging.

It seems like the handlers are not initialized if you don't call mu4e before running other functions like mu4e-update-mail-and-index

Initializing the handlers manually after loading fixed the issue for me:

(add-to-list 'load-path "/usr/local/share/emacs/site-lisp/mu4e")
(require 'mu4e)
(mu4e--init-handlers)

In my case it was (add-to-list 'load-path "/usr/share/emacs/site-lisp/mu4e"). Note the missing local

[prosoitos]

In my case it was (add-to-list 'load-path "/usr/share/emacs/site-lisp/mu4e"). Note the missing local

It's the same path for me, but this is actually unnecessary if you use Emacs installed through pacman (Arch knows where it installs things and programs are well integrated with each other).

It is only necessary to add to load-path things that are installed by the user outside of pacman (e.g. the location of elpa packages).

Now, if you compile Emacs from source or install it without pacman, then it might be necessary. But in the vast majority of cases, it shouldn't be.

[prosoitos]

@djcb I can confirm that (mu4e 'background) works great.

Thank you for the suggestion to use this instead of manually initializing the handlers.

[milouse]

Oooh I just discovered (mu4e 'background) and it might help me for other custom things. Thank you very much @djcb for pointing us to that.

About the fact that only Archlinux user are complaining: may it be because arch packages are slightly more quickly up-to-date than any other distribution, and that Arch package only push mu4e in /usr/share/emacs/site-lisp… contrary to an install through melpa or else, which may add a bunch of auto-loader, which will ensure everything is loaded as soon as possible? Wild guess here.

So, as a synthesis, the best way to properly load mu4e (at least on Archlinux ?) is the following, if you only intend to use it directly through M-x mu4e:

(add-to-list 'load-path " /path/to/your/emacs/site-lisp/mu4e/")
(require 'mu4e)

or just

(autoload 'mu4e " /path/to/your/emacs/site-lisp/mu4e/mu4e"
 "Start mu4e daemon and show its main window." t)

However, if you plan to integrate it a bit deeply with some background jobs / emacs server…, the following should be used:

(add-to-list 'load-path " /path/to/your/emacs/site-lisp/mu4e/")
(require 'mu4e)
(mu4e 'background)

which may be shortened a bit with:

(autoload 'mu4e " /path/to/your/emacs/site-lisp/mu4e/mu4e"
 "Start mu4e daemon and show its main window." t)
(mu4e 'background)

[djcb]

I've released 1.8.7, which should fix the very problem this ticket started with (not being able to find mu4e-view). Thanks for all the feedback!

[magandrez]

For the record, I have been experiencing the exact same error as in the description of this issue.

In my case the problem stemmed from the systemd unit I have created to fetch mail on schedule. On said unit, I had an ExecStartPost option to run mu4e-update-index, like below:

 ExecStartPost=/usr/bin/emacsclient --socket-name=hademacs --eval '(mu4e-update-index)'

The errors ceased to appear after requiring mu4e, like:

 ExecStartPost=/usr/bin/emacsclient --socket-name=hademacs --eval "(require 'mu4e) (mu4e-update-index)"