lordpretzel / mu4e-views Goto Github PK

Messages are still filtered when the view method is set to "html-nonblock" in the predicate view map.

To reproduce, set the default predicate view map to not filter messages, and open a message that would normally be filtered. Upon opening, the message is still filtered even though "html-nonblock" was specified.

  (setq mu4e-views-dispatcher-predicate-view-map
        `((,(lambda (msg) (mu4e-message-field msg :body-html)) . "html-nonblock")
          (,(lambda (msg) (ignore msg) t) . "text")))

I have confirmed that I am able to view the same messages without filtering using the interactive mu4e-views-mu4e-view-as-nonblocked-html. This rules out any issues with specific email content. Further, I have confirmed that if you change "html-nonblock" above to "text", the predicate map works as expected showing the plain text alternative.

Finally, I discovered this issue while building my own predicate to prevent filtering of email from senders in a list of case-insensitive domains. At first, I thought this was due to my predicate function until I tested it using the "text" view method and realized the predicate was working as expected.

  (setq mu4e-views-dispatcher-predicate-view-map
        `((,(lambda (msg)
              (let ((allow-list '("somedomain.com" "anotherdomain.com"))
                    (from-addr (cdar (mu4e-message-field msg :from)))
                    (-compare-fn (-flip (-rpartial #'string-suffix-p t))))
                (-contains-p allow-list from-addr))) . "html-nonblock")  ; If I set to "text", it works as expected
          (,(lambda (msg) (mu4e-message-field msg :body-html)) . "html")
          (,(lambda (msg) (ignore msg) t) . "text")))

The solution is to provide advice functions that make sure the message is available.

(define-key km (kbd "v") #'mu4e-view-verify-msg-popup)
(define-key km (kbd "E") #'mu4e-views-mu4e-view-save-all-attachments)
(define-key km (kbd "T") #'mu4e-view-mark-thread)
(define-key km (kbd "t") #'mu4e-view-mark-subthread)

mu4e-views now supports filtering of tracking content from emails. However, the rules are quite naive. It would be good to improve these rules implemented in mu4e-views-default-dom-filter.

Hi, for the following two advices

I want to point out that the correct mu4e function is mu4e-view-headers-prev.

When open a email from mu4e and focus on article buffer, the traditional process is to pressing 'SPACE' key repeatly.

space will scroll own mail in current article buffer, when reach current article end, i will open next article automatically.

but, after (require 'mu4e-view), broken this behavior.

mu4e-views breaks mu4e-select-other-view, bound by default to y in header and view mode. That function calls mu4e-get-view-buffer which is just:

(defun mu4e-get-view-buffer ()
  (get-buffer mu4e~view-buffer-name))

which returns nil when mu4e-views html mode is active.

It would be nice to have a drop-in replacement that searched first for the xwidget buffer and only afterwards for the default view buffer. Looking very, very quickly at our code I don't immediately see a way to do this but I hope it's possible!

Currently, the user can only turn the injection of email information into the email's html document on or off and provide one chunk of CSS code that controls how the information is displayed. It would be better to allow the user to select exactly which elements are shown and determine individually how they are shown.

It seems that using this (great!) package with xwidgets doesn't mark the message as read? Is this something I misconfigured?

This looks like a great package for dealing with all those pesky html emails that don't look right in mu4e. However, when trying it I get the following error mu4e-views-mu4e-headers-view-message: Wrong number of arguments: #<subr mu4e~proc-view>, 4. Note that this is on a native-comp version of git emacs, so maybe there is something with that or v28 of emacs? This worked on another computer without native compilation. However, when looking at the source, I do see an extra argument of verify passed to mu4e~proc-view when it only takes at most 3. Removing this fixes the issue for me. Not sure why it worked on another computer though...

This effects all marking methods, e.g., marking for read.

(define-key km (kbd "!") #'mu4e-view-mark-for-read)
(define-key km (kbd "%") #'mu4e-view-mark-pattern)
(define-key km (kbd "&") #'mu4e-view-mark-custom)
(define-key km (kbd "*") #'mu4e-view-mark-for-something)
(define-key km (kbd "+") #'mu4e-view-mark-for-flag)
(define-key km (kbd "-") #'mu4e-view-mark-for-unflag)
(define-key km (kbd "/") #'mu4e-view-search-narrow)
(define-key km (kbd "?") #'mu4e-view-mark-for-unread)
(define-key km (kbd "m") #'mu4e-view-mark-for-move)
(define-key km (kbd "r") #'mu4e-view-mark-for-refile)

Desired behavior

With both header & view buffer open using xwidgets, mu4e-compose-reply from headers buffer uses the view buffer, not the header buffer.

Actual behavior

mu4e-compose-reply uses the headers buffer:

Steps to reproduce

1. mu4e-views-select-view-msg-method html
2. open headers buffer
3. mu4e-headers-view-message on any message
4. switch to headers buffer if not already there
5. mu4e-compose-reply

Bug present In

Current master (1/16/20) 55e5467

Cause

• mu4e-compose-reply uses mu4e-compose
• mu4e-compose uses the view's buffer name to decide whether to use it for replies
• normally, the view buffer name is *mu4e-view*, but when using xwidgets it is *xwidget webkit: *

Hack workaround

in the mu4e package, change mu4e/mu4e-compose.el:776 (in the mu4e-composefunction) change:

(let ((viewwin (get-buffer-window (mu4e-get-view-buffer))))

to

(let ((viewwin (get-buffer-window "*xwidget webkit:  *")))

Notes

Not really sure what the best way to fix this is. I tried renaming the xwidget buffer to *mu4e-view* name in various places, but nothing seemed to work.

Hi, Looks like the order of the two mu4e-views-debug-log is wrong.

Thanks for this great package.

mu4e does show numbers besides each URL in an email. The following two methods need to be adapted to use completing read instead, because selecting a URL by number when numbers are not shown is meaningless.

;; since links are not shown selecting based on numbers is useless (replace with completion) or remove
(define-key km (kbd "k") #'mu4e-views-mu4e-view-save-url)
(define-key km (kbd "f") #'mu4e-views-mu4e-view-fetch-url)

Hi,
I wanted to try your package so I used the straight method:

(use-package mu4e-views :straight (mu4e-views :type git :host github :repo "lordpretzel/mu4e-views"))

However, if I try to use mu4e-views-mu4e-select-view-msg-method emacs complains with:

No such file or directory, mu4e-view-old

Any ideas why ?

I'm using:

This is GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.30, cairo version 1.16.0) of 2022-03-24

and
* mu4e - mu for emacs version 1.7.7

Thanks,

Jouke

To reproduce call mu4e-views-mu4e-view-action and select, e.g., viewing email as pdf.

Probably need to provide wrappers to either use mu4e-versions or make sure window setup works correctly.

Support bindings for evil-mode. This can be done by sending a PR to https://github.com/emacs-evil/evil-collection.

Currently the situation for evil-mode is that the bindings for mu4e-views do not work at all.

Hi, thanks again for such a cool package :-)

This is a minor nit but when I use n and p to scroll in the headers mode (no view window), mu4e-views seems to open a view window without hitting enter. This is jarring, to me at least, because it's different than upstream's behavior. Oh, and my method for email is 'html.

It's easy to reproduce on my machine: just press q to close the view window and scroll in the headers windows with n or p. This behavior is different if I set the method to 'text (which seems to behave as upstream).

The setting mu4e-views-next-previous-message-behaviour doesn't work for me, the focus of mu4e always switches to the message view after changing the email (by pressing n or p). However, I want it to stay focused on the header view. I tried both stick-to-current-window and always-switch-to-headers, but the behaviour didn't change.

I'm currently using Emacs 27.2. If you need additional information, please let me know.

We already have support for exporting emails as html or pdf. We could build on that to allow forwarding of emails as attachments.

This crashes Emacs immediately for me. I can use (xwidget-webkit-browse-url "https://www.gnu.org/") without issue. I've tried with emacs -q and a minimal mu4e config and still happens.

Not sure how to diagnose the problem. If you want more info just let me know what you need.

In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.23, cairo version 1.17.3)
Repository revision: 237fd33aef7e0f4b187ee0c1f367f27a90d603dc
Repository branch: feature/native-comp
Windowing system distributor 'The X.Org Foundation', version 11.0.12009000
System Description: Manjaro Linux

Configured using:
 'configure --with-json --with-xwidgets --with-harfbuzz --with-cairo
 --with-mailutils --with-imagemagick --with-nativecomp 'CFLAGS=-ggdb3
 -O0' LDFLAGS=-ggdb3'

I installed the package via straight.el from melpa
But I get the error Symbol’s function definition is void: dom-remove-attribute when trying to preview the email

Before, when setting this var to "t", mu4e would auto update the view as you moved with n and p. I have tried setting this up a few ways now but this doesn't appear to be working anymore.

I get the following whenever I open an email with the mu4e-view function:

Error during redisplay: (eval (when xwidget-webkit--loading-p (let ((session (xwidget-webkit-current-session))) (format " [%d%%%%]" (* 100 (xwidget-webkit-estimated-load-progress session)))))) signaled (void-function xwidget-webkit-estimated-load-progress)

Here's my xwidgets setup:

(use-package xwidget
  :straight (:type built-in)
  :defer 1
  :config
  (require 'xwidget))

I'm on GNU Emacs 29.0.50 (build 1, aarch64-apple-darwin21.3.0, NS appkit-2113.30 Version 12.2.1 (Build 21D62), git sha1 d64a1f7251).

This might be an upstream bug similar to #18, but I'm not sure so I figured I'd start a new thread.

Hi,

I installed mu4e-views this way

(use-package mu4e-views
  :straight (mu4e-views :type git :host github :repo "lordpretzel/mu4e-views" :branch "mu-1.7-support")
(...)

on

Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.34, cairo

Xwidgets is running fine here

with

mu 1.8.7

When I try to open a html-message I got this error

error in process filter: Wrong type argument: sequencep, :name

I have absolutely no idea what I can do?

Can you anyone help me?

Thanks in advance
Thorsten

Hi,

When I switch the view mode from "html" to "text", in Text view, it shows "^M" at the end of each line.

I don't see the ^M in without mu4e-views package.

Could you check this out, please?

When replying to an email, the quoted email (the one we are replying to) is written into a single line. This is a mu4e-views bug, because it does not show in mu4e if mu4e-views is not loaded. This also only shows in mu > 1.5.x

I like to use mu4e-view-use-gnus for email unless I really want to view HTML. That doesn't seem to interact well with this. Is there a way to get it to work?

A lot of internas have changed in mu 1.7 including renaming many functions from mu4e~... to mu4e--.... Furthermore, the build-in view method was completely removed, leaving only the one derived from the gnus article view. Additionally, some source files got reorganized. Let's keep track of the todos here. For now this lives in branch mu-1.7-support until it is stable enough.

Things to fix

• get to the point where we can open an email using mu4e-views html view
• attachments
  • attachment construction
    • the previous code for constructing a data structure with attachments for a message is gone, we need to revive it or see how we can use the gnus article one
  • attachment saving
  • opening attachments
  • showing inline images that were considered attachments before (see below)
• forward and reply
• view actions
  • save or open attachments actions
  • show thread
  • view in browswer
• header actions
  • show thread
  • view in browswer
• test other mu4e-views viewing methods
  • open in browser
  • pdf
  • text (just remove this one if 1.7 is detected)
  • gnus (so far everything seems to work)
  • dispatcher

New issues in 1.8

• sometimes html file gets written in an incorrect character encoding forcing the user to select the char encoding
  • this should be solvable by propagating the charset that gnus detects and using that?
• sometimes text of an email is not shown
  • it seems that gnus-article-browse-html-parts ignores some html parts containing the missing content.
• mu does not longer provide message parts as part of a message's plist. We get this from gnus, but the process is redundant, can we optimize this?

Attachments that are inline images

mu4e now uses gnus for handling attachments and there is no longer a mu server method for extracting attachments. We have a workaround for handling actual attachments that works. We construct the old mu4e attachment hashmap and then delegate to the new gnus-based code for saving attachments or opening them. However, the old code does consider inline images as attachments which we exploited to create valid links to these images in html emails to show them inline. In mu 1.7+ these are no longer considered as attachments. Thus, we need to find an alternative for extracting these types of attachments to show them in the html code we generate.

• find way to extract inline images and such as temporary files that we can link to in the html
  • this can be done with gnus extraction of message parts and the helper function gnus-article-browse-html-save-cid-content. However, this is currently only working correctly for some cases.
• apply this in mu4e-views message to html translation
• replace the workaround that generates the old attachment data structures to cache the new data structures instead for 1.7 (unnecessary work and maintenance headaches)

Supporting 1.8.x

• check for additional things that are broken when using 1.8.x

I just discovered mu4e-views yesterday and I'm loving it! I'm a Doom Emacs user, so I've had to make some tweaks to make it more comfortable in Doom, so I thought I'd share my setup thus far in case any other Doom users find this.

package.el

(package! mu4e-views)

config.el

(use-package! mu4e-views
  :after mu4e
  :config
  (setq mu4e-views-completion-method 'ivy)
  (setq mu4e-views-default-view-method "html")
  (setq mu4e-views-next-previous-message-behaviour 'stick-to-current-window) ;; when pressing n and p stay in the current window
  (setq mu4e-views-mu4e-html-email-header-style
        "<style type=\"text/css\">
.mu4e-mu4e-views-mail-headers { font-family: sans-serif; font-size: 10pt; margin-bottom: 30px; padding-bottom: 10px; border-bottom: 1px solid #ccc; color: #000;}
.mu4e-mu4e-views-header-row { display:block; padding: 1px 0 1px 0; }
.mu4e-mu4e-views-mail-header { display: inline-block; text-transform: capitalize; font-weight: bold; }
.mu4e-mu4e-views-header-content { display: inline-block; padding-right: 8px; }
.mu4e-mu4e-views-email { display: inline-block; padding-right: 8px; }
.mu4e-mu4e-views-attachment { display: inline-block; padding-right: 8px; }
</style>"
        )

  (add-hook! mu4e-headers-mode
    (mu4e-views-mu4e-use-view-msg-method "html")) ;; select the default

  (map! :map mu4e-headers-mode-map
        :n "M-b" #'mu4e-views-cursor-msg-view-window-up
        :n "M-f" #'mu4e-views-cursor-msg-view-window-down
        :localleader
        :desc "Message action"        "a"   #'mu4e-views-mu4e-view-action
        :desc "Scoll message down"    "b"   #'mu4e-views-cursor-msg-view-window-up
        :desc "Scoll message up"      "f"   #'mu4e-views-cursor-msg-view-window-down
        :desc "Open attachment"       "o"   #'mu4e-views-mu4e-view-open-attachment
        :desc "Save attachment"       "s"   #'mu4e-views-mu4e-view-save-attachment
        :desc "Save all attachments"  "S"   #'mu4e-views-mu4e-view-save-all-attachments
        :desc "Set view method"       "v"   #'mu4e-views-mu4e-select-view-msg-method)) ;; select viewing method)


;; Evil bindings for xwidget webkit browsers
(map! :map xwidget-webkit-mode-map
      :n "Z Z" #'quit-window
      :n "gr"  #'xwidget-webkit-reload
      :n "y"   #'xwidget-webkit-copy-selection-as-kill
      :n "s-c" #'xwidget-webkit-copy-selection-as-kill
      :n "t"   #'xwidget-webkit-browse-url
      :n "TAB" #'xwidget-webkit-forward
      :n "C-o" #'xwidget-webkit-back
      :n "G"   #'xwidget-webkit-scroll-bottom
      :n "gg"  #'xwidget-webkit-scroll-top
      :n "C-b" #'xwidget-webkit-scroll-down
      :n "C-f" #'xwidget-webkit-scroll-up
      :n "M-=" #'xwidget-webkit-zoom-in
      :n "M--" #'xwidget-webkit-zoom-out
      :n "k"   #'xwidget-webkit-scroll-down-line
      :n "j"   #'xwidget-webkit-scroll-up-line)

I get this error when use with newest mu4e 1.5.14

error in process filter: if: Cannot use gnus-based view with old view loaded; restart emacs.

i guess this issue caused by require mu4e-view-old

(if (version-list-<=  '(1 5 0) (version-to-list mu4e-mu-version))
    (require 'mu4e-view-old))

and, then this message come from mu4e-view.el in the offical package.