Closed milouse closed 11 months ago
(I also lookup first in previous issues, but #1213, #1543 or #389 are not related)
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.
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)
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.
I can confirm it is working as expected now.
Great, thanks!
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.
When I replied to this message with those settings, I got:
Friday 17 November 2023 à 01:35, notifications@github.com a écrit :
which seems correct (apart from mixing French and English :))
Can you attach a message where you see this problem? Thanks.
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?
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.
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.
Describe the bug
Given the following configuration:
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:(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
Checklist
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
callmu4e-compose-reply
(mu4e-compose 'reply)
mu4e~compose-handler
mu4e-compose-parent-message
mu4e-draft-open
to pre-fill the new draftmu4e~draft-reply-construct
with the original message as parametermu4e~draft-cite-original
always with the original message as parameter(funcall mu4e-compose-cite-function)
. In my (default) case,mu4e-compose-cite-function
is bound tomessage-cite-original-without-signature
(funcall message-citation-line-function)
To summarize:
message-citation-line-function
is called without any parameter and I’m totally ok with that.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 ofmu4e~draft-cite-original
is run in awith-temp-buffer
form and thatmu4e-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):
mu4e~view-message
and be sure it targets the right message, even when called from the header view (meaning setting it inmu4e-compose
function?mu4e~draft-cite-original
to ensuremu4e-compose-parent-message
andmu4e-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.