First view of newly arrived message does not display inline images.

[Hippo Potamus]

I'm noticing what seems to be a recurrence of an issue that was mentioned here a year or so ago in the following thread:
https://groups.google.com/forum/#!searchin/mu-discuss/twice|sort:relevance/mu-discuss/UWsUevRn1Mw/77YMxtJySjMJ

The first time a newly arrived email is viewed, its inline images are not displayed. However, if I exit back to header mode and view the message a second time, the inline images will then show up.

The problem seems to be related to the following: in mu4e-view.el, there is a function called mu4e~view-show-images-maybe. Within that function, see the following line:

        (let ((imgfile (mu4e-message-part-field part :temp)))

The first time a message with an attachement is viewed, "imgfile" is set to nil. Only after exiting back to the headers buffer and viewing the message a second time does (mu4e-message-part-field part :temp) return a non-nil result.

I'm guessing that there is some sort of caching or indexing of message parts that has to take place before `mu4e-message-part-field' will return a non-nil value. It appears that this caching or indexing doesn't take place until after a newly arrived message is viewed for the first time.

I'm using the latest mu4e release: version 0.9.18 (under GNU emacs 25.1.13). I also had the same problem under the previous mu4e version, 0.9.17. Imagemagick is compiled into the emacs that I'm using, and I've configured mu4e to use it. I'm using offlineimap to manage my email.

.

[Hippo Potamus]

PS: The Attachments: header in newly arrived messages indeed properly shows the existence of the image file, even though the file is not shown inline.

Furthermore, I can issue the "e" command (mu4e-view-save-attachment), and it indeed works properly and saves the attachment, even though the image is not showing inline.

It therefore appears that the message structure is almost complete during the first view of a newly arrived message. Only the :temp attribute seems to not get set until the message is viewed the second and subsequent times.

.

[Hippo Potamus]

PPS: I'm guessing that this behavior might be due to the fact that I'm using maildirs, and that the newly arrived message is sitting in the INBOX's "tmp" subdirectory after it first arrives. It only gets moved to the "cur" subdirectory as the message is first being viewed.

It might be that the code which assigns the :temp attribute might fail when the message is still in the "tmp" directory, and that the message needs to be in the "cur" subdirectory before :temp can be properly assigned.

But like I said, this is just a guess.

Anyway, the weekend is ending, and I will be busy with my day job for the next 5 days, so I won't be able to do any more diagnosis of this isssue.

Perhaps one or more of you who understand the internals of mu4e could offer some insights.

Thank you very much.

.

[Christophe Troestler]

See https://github.com/djcb/mu/issues/447

> --
> You received this message because you are subscribed to the Google
> Groups
> "mu-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to
> mu-discuss+...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Hippo Potamus]

On Monday, January 30, 2017 at 3:10:34 AM UTC-5, Christophe Troestler wrote:

See https://github.com/djcb/mu/issues/447

Thank you very much. However, unless I'm missing something, there doesn't appear to be any workable solution to this problem mentioned in this referenced discussion.

Also, the guess that I offered above turns out to be incorrect. Even if the message is moved from the "tmp" folder to the "cur" folder, the first view of the message in mu4e still does not show the images.

The problem is definitely due to the :temp attribute not being set for the initial view of the message. More diagnosis is necessary in order to determine why.

In my spare time, I'll continue to look into this.

.

 

[Hippo Potamus]

I still haven't figured out the cause of the missing :temp attribute, but now I've at least come up with a workaround.

As I mentioned above, in mu4e-view.el, there is a function called mu4e~view-show-images-maybe which contains the following line:

        (let ((imgfile (mu4e-message-part-field part :temp)))

Immediately underneath this line, insert the following code:

             (unless imgfile
               (let* ((name (mu4e-message-part-field part :name))
                      (docid (mu4e-message-field msg :docid))
                      (index (mu4e-message-part-field part :index))
                      (n 50)
                      (wait 0.1))
                 (setq imgfile (format "%s%s" temporary-file-directory name))
                 (mu4e~proc-extract 'save docid index mu4e-decryption-policy imgfile)
                 (while (and (> n 0) (not (file-exists-p imgfile)))
                   (setq n (1- n))
                   (sleep-for wait))
                 (mu4e-remove-file-later imgfile)))

This is an ugly hack, but it at least gets the job done.

I'll continue to investigate the problem involving the missing :temp attribute in my spare time.

Excelsior!

.

[xinfa tang]

The same problem for me, but if i disable `mu4e-view-auto-mark-as-read` the problem fixed:
    (setq mu4e-view-auto-mark-as-read nil)

When `mu4e-view-auto-mark-as-read` is enabled(by default), the mail we view will display twice one by one:
   1, the first triggered when we press `ENTER` in `*mu4e-headers*` buffer, calls `mu4e-headers-view-message` function, it send `view` command to `mu`, `mu` responsed a `msg` with image(by :temp field), `mu4e` display this msg
   2, the second triggered by `mu4e-view-auto-mark-as-read` settings, it send a `move` command to `mu`, `mu` responsed a `msg` leak image, `mu4e` display this msg

We can fix it in `mu` source code, modify `mu-cmd-server.c` `do_move` function:
from:
       sexp = mu_msg_to_sexp (msg, docid, NULL, MU_MSG_OPTION_VERIFY);
to:
       sexp = mu_msg_to_sexp (msg, docid, NULL, MU_MSG_OPTION_VERIFY|MU_MSG_OPTION_EXTRACT_IMAGES);
      
在 2017年1月30日星期一 UTC+8上午6:35:37，Hippo Potamus写道：

[xinfa tang]

Fix it without modify `mu` and `mu4e`,  just trigger a another view action when msg update:

(defun my/mu4e-update-func (msg is-move)
    (with-current-buffer (mu4e-get-headers-buffer)
      (when (mu4e~headers-goto-docid (mu4e-message-field msg :docid))
        (mu4e-headers-view-message))
      ))
  (setq mu4e-update-func 'my/mu4e-update-func)

在 2017年1月30日星期一 UTC+8上午6:35:37，Hippo Potamus写道：

I'm noticing what seems to be a recurrence of an issue that was mentioned here a year or so ago in the following thread: