[mu4e bug] Original message date no more taken into account in citation line

[milouse]

Describe the bug

Given the following configuration:

(setq message-citation-line-format "%a %d %b %Y à %R, %n a écrit :\n"
      message-citation-line-function #'message-insert-formatted-citation-line)

And an email received the 2021-08-26 at 15:03.

Either by hitting R in *mu4e-headers* or in the related *Article* buffer, I got the following citation line:

jeu. 01 janv. 1970 à 01:00, [email protected] a écrit :

(I think I don’t have to translate, the displayed date is 1970-01-01 at 00:00 UTC, i.e. date is nil)

Before mu 1.6 it worked as expected (as far as I can remember)

Environment

• mu for emacs version 1.6.4
• GNU Emacs 27.2
• Archlinux

Checklist

• [X] you are running vanilla emacs (i.e. without Doom, Evil, Spacemacs etc.) (otherwise, please try to reproduce without those
• [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).

Interesting things

I began to dig a bit to try to fix that.

I discover that answering an email follow that path (if I’m not wrong):

• R call mu4e-compose-reply
• which just call (mu4e-compose 'reply)
• which will call after some refinement mu4e~compose-handler
  • this one temporarily make the original message available for hook in the variable mu4e-compose-parent-message
  • then it call mu4e-draft-open to pre-fill the new draft
  • doing that it call mu4e~draft-reply-construct with the original message as parameter
  • which in turn call mu4e~draft-cite-original always with the original message as parameter
  • which (funcall mu4e-compose-cite-function). In my (default) case, mu4e-compose-cite-function is bound to message-cite-original-without-signature
  • which finally (funcall message-citation-line-function)

To summarize:

• message-citation-line-function is called without any parameter and I’m totally ok with that.
• However, when it is called, the only thing that function can access is the new draft buffer, without any information about the original message.
• So the only viable way seems to use my own message-citation-line-function and somehow get the original message date by an other mean. I am also totally ok with that. But:
  • mu4e~view-message is not a reliable source for the original message, as we can begin to answer a message from the header view, without having opened it first. In that case, mu4e~view-message will still refer to the previously opened message, which can be different.
  • mu4e-compose-parent-message does not seem to be accessible any more at that step. If I’m not wrong it is because the content of mu4e~draft-cite-original is run in a with-temp-buffer form and that mu4e-compose-parent-message is buffer local (and not the same).

So at this point I feel a bit stuck and I don’t know if I’m the only one in that case or not :/

Two possible solution (for me):

• make use of mu4e~view-message and be sure it targets the right message, even when called from the header view (meaning setting it in mu4e-compose function?
• fixing mu4e~draft-cite-original to ensure mu4e-compose-parent-message and mu4e-compose-type are still available in the temp buffer.

What do you think?

If you confirm this problem (I may be totally wrong and in that case I’d like to appologize for my misunderstanding), I’m totally willing to open a PR fixing the problem, but I’d like to discuss the different solution we could adopt first. I think I’d prefer my second solution, but maybe you’ll have another idea.

[milouse]

(I also lookup first in previous issues, but #1213, #1543 or #389 are not related)

[djcb]

As you've noticed, the whole setup is a bit convoluted, so many steps! I'm planning to rework it a bit in the 1.7 time-frame (which starts soon)... let's make sure it gets a bit easier for your use-case and others.

[milouse]

Ok, it worths to know it.

In the mean time, I work around the problem with the following code in my setting file:

(defvar ed/mu4e~original-message)

(defun ed/message-insert-citation-line (&optional from date _tz)
  (when ed/mu4e~original-message
    (unless date
      (setq date (mu4e-message-field ed/mu4e~original-message :date)))
    (message-insert-formatted-citation-line from date)))

(defun ed/mu4e-setup-original-message ()
  "Put `mu4e-compose-parent-message' in `ed/mu4e~original-message'.

Because the parent message is lost when it become usefull for inserting
citation line."
  (when (member mu4e-compose-type '(reply forward))
    (setq ed/mu4e~original-message mu4e-compose-parent-message)))

(defun ed/mu4e-reset-original-message ()
  "Reset `ed/mu4e~original-message' to avoid weird thing."
  (setq ed/mu4e~original-message nil))

(add-hook 'mu4e-compose-pre-hook #'ed/mu4e-setup-original-message)
(add-hook 'mu4e-compose-mode-hook #'ed/mu4e-reset-original-message)

[djcb]

This seems to work fine with the new composer, closing this.

Note: mu4e 1.11.23 has a new composer that is much closer to gnus' one, so various message- settings have better odds to work in mu4e as well.

[milouse]

I can confirm it is working as expected now.

[djcb]

Great, thanks!

[milouse]

Actually, it seems there is still a problem. After having desactivated my previous patch, and thus only relying on the following settings:

message-citation-line-format "%A %d %B %Y à %R, %n a écrit :\n"
message-citation-line-function #'message-insert-formatted-citation-line

the month name (%B) and day name (%A) are wrong. Right now it will display "janvier" and "mardi", when it should be "novembre" and "vendredi". The day number (%d) and the time are correctly extracted. Thus I suspect their is an issue when extracting the date, what leads to an unknown month.

So I reactivated my fix for now. I’ll try to investigate what is going on with default settings.

[djcb]

When I replied to this message with those settings, I got:

Friday 17 November 2023 à 01:35, [email protected] a écrit :

which seems correct (apart from mixing French and English :))

Can you attach a message where you see this problem? Thanks.

[milouse]

Actually all messages are impacted (even the notifications from github).

I got some interesting result: when I start emacs "normally", and thus inherit from my system settings (LANG=fr_FR) I got the bug (the date appears in "janvier" (january) instead of the correct month). But if I start emacs from the terminal by overwriting the locale setting (i.e. LANG=en_US.UTF8 emacs) I don’t have the bug (the correct date is picked).

Could it be that some inner function expect an english date to be parsed, and some intermediary process already translate the date into french too soon, leading to the parsing to fail?

[milouse]

Oh, yes I can confirm it. Per the message-insert-formatted-citation-line documentation, it is expected to receive the date from the date header of the email. In my case the date header is translated into french. I think the problem is here: instead of using the original header date, the function is called with the displayed (translated) header date. What fails to understand the french days and months. I’ll try to confirm this problem.

[milouse]

I confirm the issue comes from the message.el package :/ in the message-reply function, it use (message-fetch-field "date") to get the date, which returns a translated date.

I’m surprised I’m the only one using Emacs in a non english environment 😲

I’m not sure what to do now to have this fully working, apart for creating my own formatting function understanding french locale.