Change in behaviour of mu4e-message-at-point with gnus view mode?

[Alex Bennée]

Hi,

I'm seeing weird behaviour where mu4e-message-field-at-point (and the
related mu4e-message-at-point) stop working. It will work in the
*Article* buffer and then when I go and do something else and return to
the *Article* buffer it replies with:

[mu4e] No message at point

It seems mu4e~view-message is getting nerfed at some point. Does anyone
have any idea what might be doing that or how I could track it happening?

--
Alex Bennée

[Dirk-Jan C. Binnema]

There were a few cases where mu4e thought there *was* a message when it
shouldn't; this smells like some fallout from that fix. Do you have
steps to repro? Feel free to file a ticket.

Kind regards,
Dirk.

--
Dirk-Jan C. Binnema Helsinki, Finland
e:dj...@djcbsoftware.nl w:www.djcbsoftware.nl
gpg: 6987 9CED 1745 9375 0F14 DA98 11DD FEA9 DCC4 A036

[Alex Bennée]

"Dirk-Jan C. Binnema" <dj...@djcbsoftware.nl> writes:

> On Friday Aug 12 2022, Alex Bennée wrote:
>
>> Hi,
>>
>> I'm seeing weird behaviour where mu4e-message-field-at-point (and the
>> related mu4e-message-at-point) stop working. It will work in the
>> *Article* buffer and then when I go and do something else and return to
>> the *Article* buffer it replies with:
>>
>> [mu4e] No message at point
>>
>> It seems mu4e~view-message is getting nerfed at some point. Does anyone
>> have any idea what might be doing that or how I could track it happening?
>
> There were a few cases where mu4e thought there *was* a message when it
> shouldn't; this smells like some fallout from that fix. Do you have
> steps to repro? Feel free to file a ticket.

Do you know which commit that was?

So far I haven't found an explicit repro other than "wait a bit and then
try and read email.". My entry helper function falls over when it does:

;; What are we reading
(let ((view (or (get-buffer "*mu4e-view*") (get-buffer "*Article*"))))
(when view
(push (propertize
(format "reading:%s"
(with-current-buffer view
(mu4e-message-field-at-point :subject)))
'buffer view) collection)))

>
> Kind regards,
> Dirk.
>
> --
> Dirk-Jan C. Binnema Helsinki, Finland
> e:dj...@djcbsoftware.nl w:www.djcbsoftware.nl
> gpg: 6987 9CED 1745 9375 0F14 DA98 11DD FEA9 DCC4 A036

--
Alex Bennée

[Tim Cross]

I have noticed this a couple of times as well. For me, it comes up when
I try to reply to a message when I'm in the message article buffer. I
get the no message at point error. I then exit the article, back to the
header view, and can reply to the message from there with no error.

It ahs only happened a couple of times. Most of the time, all works
fine. Not sure on what triggers it or how to reproduce it. However, it
does 'feel' like it is triggered when I've left an article buffer open
and then go off and do something else, coming back to the message after
some time and then trying to reply.

[Christophe Troestler]

Hi,

With mu 6fdc20ae, clicking or pressing ENTER on pdf attachments (gnus-article-press-button) always displays “user-error: [mu4e] No message at point”. It works for other types of attachments (say text or HTML ones). Saving PDF attachments also work.

Have a nice day,
Christophe

[Dirk-Jan C. Binnema]

Please try 1.8.9, which has a (candidate) fix.

[Dirk-Jan C. Binnema]

On Saturday Aug 13 2022, Christophe Troestler wrote:

> With mu 6fdc20ae, clicking or pressing ENTER on pdf attachments
> (gnus-article-press-button) always displays “user-error: [mu4e] No message at
> point”. It works for other types of attachments (say text or HTML ones). Saving
> PDF attachments also work.

That seems to be a different issue(?) Can't reproduce that in any case.

If you can (with 1.8.9) please file a ticket with a backtrace, thanks!

[Christophe Troestler]

On 15 August 2022 at 23:26 +03, "Dirk-Jan C. Binnema" <dj...@djcbsoftware.nl> wrote:
> On Saturday Aug 13 2022, Christophe Troestler wrote:
>
>> With mu 6fdc20ae, clicking or pressing ENTER on pdf attachments (gnus-article-press-button) always displays “user-error: [mu4e] No message at point”. It works for other types of attachments (say text or HTML ones). Saving PDF attachments also work.
>
> That seems to be a different issue(?) Can't reproduce that in any case.

I upgraded to 1.8.9 and the issue still persists.

I started to track it and the problem comes from `gnus-mm-display-part`. In that function `(mm-handle-displayed-p handle)` — where `handle` comes from `(get-text-property (point) 'gnus-data)` — returns `nil` instead of a “true” value (if I change it to `t`, the PDF program is launched on the appropriate file).

The definition of
#+begin_src elisp
(defun mm-handle-displayed-p (handle)
"Say whether HANDLE is displayed or not."
(mm-handle-undisplayer handle))
#+end_src

and

#+begin_src elisp
(defmacro mm-handle-undisplayer (handle)
`(nth 3 ,handle))
#+begin_src elisp

Here is an example of `handle` (using `(get-text-property (point) 'gnus-data)` on the PDF button):

#+begin_src elisp
(#<buffer *mm*-945238> ("application/pdf") base64 nil ("attachment" (filename . "320625117357-4068610069-ticket.pdf")) nil nil nil)
#+begin_src elisp

> If you can (with 1.8.9) please file a ticket with a backtrace, thanks!

There is no backtrace even with “Enter debugger on error”.

Kind regards,
C.

[Christophe Troestler]

The problem is the commit ad7f5cac92004407a6841e36cdeb614c2c52072f. If I revert the definition of `mu4e-message-at-point` to

#+begin_src elisp
(defsubst mu4e-message-at-point (&optional noerror)
"Get the message s-expression for the message at point.
Either the headers buffer or the view buffer, or nil if there is
no such message. If optional NOERROR is non-nil, do not raise an
error when there is no message at point."
(let ((msg (or (get-text-property (point) 'msg) mu4e~view-message)))
(if msg
msg
(unless noerror (mu4e-warn "No message at point")))))
#+end_src

then it works again.

[Dirk-Jan C. Binnema]

On Tuesday Aug 16 2022, Christophe Troestler wrote:

But that doesn't involve `mu4e-message-at-point', so something else must
be at play.

[Christophe Troestler]

On 16 August 2022 at 09:24 +03, "Dirk-Jan C. Binnema" <dj...@djcbsoftware.nl> wrote:
>> […] But that doesn't involve `mu4e-message-at-point', so something else must be at play.

Yes, see the next message (attached below for your convenience).

Best,
C.

[Christophe Troestler]

The problem is that, when I click on the link, the `major-mode` reported is `fundamental-mode`.

#+begin_src elisp
(defsubst mu4e-message-at-point (&optional noerror)
"Get the message s-expression for the message at point.
Either the headers buffer or the view buffer, or nil if there is
no such message. If optional NOERROR is non-nil, do not raise an
error when there is no message at point."

(or (cond
((eq major-mode 'mu4e-headers-mode) (get-text-property (point) 'msg))
((eq major-mode 'mu4e-view-mode) mu4e~view-message))

(unless noerror (mu4e-warn "No message at point"))))

#+end_src

[Christophe Troestler]

So, the following works (clicking or pressing ENTER on the “buttons” (links) displays the attachment) for me:

#+begin_src elisp
(defsubst mu4e-message-at-point (&optional noerror)
"Get the message s-expression for the message at point.
Either the headers buffer or the view buffer, or nil if there is
no such message. If optional NOERROR is non-nil, do not raise an
error when there is no message at point."
(or (cond
((eq major-mode 'mu4e-headers-mode) (get-text-property (point) 'msg))

((member major-mode '(mu4e-view-mode fundamental-mode))

[Dirk-Jan C. Binnema]

On Tuesday Aug 16 2022, Christophe Troestler wrote:

I can see how that would make a difference, but I still don't understand
how we get from gnus-mm-display-part to mu4e-message-at-point (it
doesn't for me). Do you have some some special hooks / overrides?

[Christophe Troestler]

On 16 August 2022 at 10:33 +03, "Dirk-Jan C. Binnema" <dj...@djcbsoftware.nl> wrote:
> […] I can see how that would make a difference, but I still don't understand how we get from gnus-mm-display-part to mu4e-message-at-point (it doesn't for me). Do you have some some special hooks / overrides?

Got it! I had a function set to `gnus-blocked-images` that was using `(mu4e-message-at-point)` to check whether the message was coming from specific addresses for which I'm OK to enable remote images. I replaced `(mu4e-message-at-point)` by `mu4e~view-message` and it is now OK.

That was really an unexpected consequence!

Sorry for the noise!

Kind regards,
C.

[Dirk-Jan C. Binnema]

On Tuesday Aug 16 2022, Christophe Troestler wrote:

Overall, mu4e-message-at-point got a little stricter so when point is
_not_ on a message, it should yield nil, even when somewhere in your
emacs there happens to be a a message; this was involved in some bug.

Using mu4e~view-message directly is not an ideal solution, since this
depends on some internal implementation detail that may very well
change. Perhaps set `gnus-inhibit-images` / `gnus-blocked-images` from
mu4e-view-mode-hook?