Arch Linux User Repository

Many thanks for these hints. The 'mu4e-view-*' are the culprits indeed. They are still used in BBDB customization, see mu4e manual. I have removed them and it seems that BBDB integration still works, at least auto-completion.

@dordow yes with this new release, mu4e now uses gnus as default viewer for the messages. You can either use the following variable to stick with the old view system (setq mu4e-view-use-old t) (however, as it is now deprecated, maybe one day it will be removed?), or try to adopt the new view (like I did). As you, I prefer the text view by default and achieve something good with the following settings:

(setq gnus-inhibit-images t ;; don't include pictures in messages
      ;; Use a custom date/time format in the Date mail header
      gnus-article-date-headers 'user-defined
      gnus-article-time-format "%A %d %B %Y à %R"
      ;; Use specific faces for To and Flags headers to look like the old mu4e view
      gnus-header-face-alist '(("From" nil gnus-header-from)
                               ("Subject" nil gnus-header-subject)
                               ("Newsgroups:.*," nil gnus-header-newsgroups)
                               ("To:" nil gnus-header-from)
                               ("Flags:" nil font-lock-builtin-face)
                               ("" gnus-header-name gnus-header-content))
      ;; Improve default order for headers
      gnus-sorted-header-list '("^From:" "^Reply-To:" "^To:" "^Cc:" "^Subject"
                                "^Date:" "^Flags:")
    ;; Never try to load html version of email by default
    mm-text-html-renderer 'w3m-standalone
    mm-discouraged-alternatives '("text/html"))

If you use the new Gnus message view, you should also check in you own config (.emacs file) that you don't keep old and deprecated variables related to mu4e-view. You must look for all variables beginning by mu4e-view and remove them as they won’t work anymore (I think that’s why you had an error message saying error in process filter: No buffer named mu4e-view: you probably have an old setting trying to do something in mu4e-view, but it is no more there.

OK, it does now format the message without error but as a single line so the message is still unreadable. The same with emacs in command line mode. It looks as if all line breaks are removed. Before migrating, the messages were in text mode (which I prefer), now they seem to be in a somewhat more fancy format

Maybe it has something to do with this item from the release notes?

*** mu4e

    - Use the gnus-based message viewer as the default; the new viewer has quite
      a few extra features compared to the old, mu4e-specific one, such as
      faster crypto, support for S/MIME, syntax-highlighting, calendar
      invitations and more.

      The new view is superior in most ways, but if you still depend on
      something from the old one, you can use:
      #+begin_example
      ;; set *before* loading mu4e; and restart emacs if you want to change it
      ;; users of use-packag~ should can use the :init section for this.
      (setq mu4e-view-use-old t)
      #+end_example

      (The older variable ~mu4e-view-use-gnus~ with the opposite meaning is
      obsolete now, and no longer in use).

Yes, I did. I have downgraded mu, then mu4e worked as usual. I upgraded again, now it is 1.6.1, run mu init and mu index. but error remains. Any special settings in .emacs I need to consider?

@dordow: did you update mu init ?

call mu init with your preferred parameters (maildir, email addresses), and then call mu index

I use mu with mu4e, and I have trouble with the latest upgrade to 1.6.0. In the message view the message is not formatted, it looks as if it is in raw format, and there is an error message: "error in process filter: No buffer named mu4e-view".

I run mu init, but this did not help. Do I need to adjust any settings in the .emacs file?

I have noticed that a new version of mu is available, 1.6.1.

Thanks in advance

Nothing to be sorry for :) Thanks for trying to improve this package!

Oh, ok, I didn't know that. Sorry for the noise!

No, it wont fail. make depends on guile and make is required to be installed on any system that wants to build packages. It probably makes sense to add guile to makedepends though.