mh-e-users — Forum for MH-E users.

Re: draft patch set for SF#473 fix (remember dest with thread refile)

[Mike K. <ku...@ra...>]

Bill Wohler via mh-e-devel wrote:

> I'd concur with Henrique assessment that his other patches were for
> XEmacs as well, which we no longer support.

Yeah, I dug into this some more.  Henrique got added to the AUTHORS file
in 2011, which is about the same time as some XEmacs-related changes in
the separate repo; the commit comments for those changes have a
thank-you that mentions Henrique.

> In any case, let's not worry about it too much and stick with the four
> lines that we do have documentation for. Thanks!

Agreed.  Henrique's 2011 changes were most likely removed as part of the
big cleanup to remove the XEmacs support back in 2021.

cheers,
mike

Re: draft patch set for SF#473 fix (remember dest with thread refile)

[Bill W. <wo...@ne...>]

I only got one hit in the logs for a different file.

    commit 1a98ebdffb
    Author: Bill Wohler <wo...@ne...>
    Date:   Wed Jul 11 05:58:45 2007 +0000

	(mh-display-color-cells): Fix on XEmacs 21.5b28. Thanks to Henrique
	Martins for the help (closes SF #1749774).

    M       lisp/mh-e/ChangeLog
    M       lisp/mh-e/mh-compat.el

Looking at the diff, I'd attribute maybe a couple of lines to Henrique.
Not that it matters since mh-compat.el no longer exists.

I'd concur with Henrique assessment that his other patches were for
XEmacs as well, which we no longer support.

In any case, let's not worry about it too much and stick with the four
lines that we do have documentation for. Thanks!

Henrique Martins <mh-...@ma...> wrote:

> mike> Henrique, how many lines do you think you have submitted to Emacs?
> 
> I guess "think" was the keyword in there.
> 
> mike> It just occurred to me to check etc/AUTHORS, and Henrique has credit for
> mike> changes to mh-mime.el and mh-xface.el.
> 
> I somewhat remember having to change something in mh-xface, maybe for (when I was on) xemacs. Not sure about mh-mime, maybe when I was upset about utf-8 encoding if from/to/etc headers.
> 
> Don't remember submitting patches. Maybe a couple of lines in some email to the list? Maybe told Bill to not credit me?
> 
> -- Henrique

-- 
Bill Wohler <wo...@ne...> aka <Bil...@na...>
http://www.newt.com/wohler/, GnuPG ID:610BD9AD

Re: draft patch set for SF#473 fix (remember dest with thread refile)

[Henrique M. <mh-...@ma...>]

mike> Henrique, how many lines do you think you have submitted to Emacs?

I guess "think" was the keyword in there.

mike> It just occurred to me to check etc/AUTHORS, and Henrique has credit for
mike> changes to mh-mime.el and mh-xface.el.

I somewhat remember having to change something in mh-xface, maybe for (when I was on) xemacs. Not sure about mh-mime, maybe when I was upset about utf-8 encoding if from/to/etc headers.

Don't remember submitting patches. Maybe a couple of lines in some email to the list? Maybe told Bill to not credit me?

-- Henrique

Re: draft patch set for SF#473 fix (remember dest with thread refile)

[Mike K. <ku...@ra...>]

It just occurred to me to check etc/AUTHORS, and Henrique has credit for
changes to mh-mime.el and mh-xface.el.  I can't find the changes in the
git history, though.

mike

Bill Wohler via mh-e-devel wrote:

> Cool.
> 
> Now you're up to 4 :-).
> 
> Henrique Martins <mh-...@ma...> wrote:
> 
> > > Finally, the 15 lines is cumulative. Henrique, how many lines do you think you have submitted to Emacs?
> > 
> > Zero :-)
> > 
> > -- Henrique
> > 
> > 
> > _______________________________________________
> > mh-e-devel mailing list
> > mh-...@li...
> > https://lists.sourceforge.net/lists/listinfo/mh-e-devel
> > 
> 
> -- 
> Bill Wohler <wo...@ne...> aka <Bil...@na...>
> http://www.newt.com/wohler/, GnuPG ID:610BD9AD
> 
> 
> _______________________________________________
> mh-e-devel mailing list
> mh-...@li...
> https://lists.sourceforge.net/lists/listinfo/mh-e-devel

Re: draft patch set for SF#473 fix (remember dest with thread refile)

[Henrique M. <mh-...@ma...>]

> Looks good, thanks again! I'm looking forward to hearing whether it works to Henrique's satisfaction.

Satisfied,

-- Henrique

Re: draft patch set for SF#473 fix (remember dest with thread refile)

[Bill W. <wo...@ne...>]

Mike Kupfer <ku...@ra...> wrote:

> Bill Wohler wrote:
> 
> > I might tweak the docstring to match the one in mh-refile-msg, namely:
> > 
> >     In a program, the variables `mh-last-destination' and
> >     `mh-last-destination-folder' are not updated if
> >     DONT-UPDATE-LAST-DESTINATION-FLAG is non-nil."
> > 
> > We use that prefix (In a program) pretty consistently. 
> 
> I added "In a program", but I otherwise kept my wording, to avoid the
> double-negative and passive voice that mh-refile-msg has.

Agreed, thanks!

> > If the notation \\='mh-last-destination-folder' is a more modern way
> > to write `mh-last-destination-folder`, then I'd stick with the \\='
> > symbol you used.
> 
> I think I got confused about the quoting conventions.  After rereading
> the documentation guidelines in Info, I've changed it to a backtick.
> It's now
> 
>   "Refile (output) thread into FOLDER.
> In a program, update the variables `mh-last-destination' and
> `mh-last-destination-folder' unless DONT-UPDATE-LAST-DESTINATION-FLAG is
> non-nil."
> 
> > I'd also remove the extra space after folder in mh-thread-refile:
> > 
> >     (folder  &optional dont-update-last-destination-flag)
> 
> Fixed (well spotted).
> 
> I've attached the revised patch#2; the first and third patches are the
> same as before.

Looks good, thanks again! I'm looking forward to hearing whether it
works to Henrique's satisfaction.

> thanks,
> mike
> >From 9ac4121684f2beb0c29b7432e9b5f48423930149 Mon Sep 17 00:00:00 2001
> From: Mike Kupfer <ku...@ra...>
> Date: Wed, 25 Mar 2026 12:14:27 -0700
> Subject: [PATCH 2/3] Improve previous change.
> 
> * lisp/mh-e/mh-thread.el: Require 'mh-folder.
> (mh-thread-refile): Update the docstring.
> ---
>  lisp/mh-e/mh-thread.el | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/lisp/mh-e/mh-thread.el b/lisp/mh-e/mh-thread.el
> index 00351b730c3..b21b23483c7 100644
> --- a/lisp/mh-e/mh-thread.el
> +++ b/lisp/mh-e/mh-thread.el
> @@ -73,6 +73,7 @@
>  
>  (require 'mh-e)
>  (require 'mh-scan)
> +(require 'mh-folder)
>  
>  (cl-defstruct (mh-thread-message (:conc-name mh-message-)
>                                   (:constructor mh-thread-make-message))
> @@ -193,8 +194,11 @@ mh-thread-previous-sibling
>    (mh-thread-next-sibling t))
>  
>  ;;;###mh-autoload
> -(defun mh-thread-refile (folder  &optional dont-update-last-destination-flag)
> -  "Refile (output) thread into FOLDER."
> +(defun mh-thread-refile (folder &optional dont-update-last-destination-flag)
> +  "Refile (output) thread into FOLDER.
> +In a program, update the variables `mh-last-destination' and
> +`mh-last-destination-folder' unless DONT-UPDATE-LAST-DESTINATION-FLAG is
> +non-nil."
>    (interactive (list (intern (mh-prompt-for-refile-folder))))
>    (cond ((not (memq 'unthread mh-view-ops))
>           (error "Folder isn't threaded"))
> -- 
> 2.39.5
> 
> _______________________________________________
> mh-e-devel mailing list
> mh-...@li...
> https://lists.sourceforge.net/lists/listinfo/mh-e-devel

-- 
Bill Wohler <wo...@ne...> aka <Bil...@na...>
http://www.newt.com/wohler/, GnuPG ID:610BD9AD

Re: draft patch set for SF#473 fix (remember dest with thread refile)

[Mike K. <ku...@ra...>]

Bill Wohler wrote:

> I might tweak the docstring to match the one in mh-refile-msg, namely:
> 
>     In a program, the variables `mh-last-destination' and
>     `mh-last-destination-folder' are not updated if
>     DONT-UPDATE-LAST-DESTINATION-FLAG is non-nil."
> 
> We use that prefix (In a program) pretty consistently. 

I added "In a program", but I otherwise kept my wording, to avoid the
double-negative and passive voice that mh-refile-msg has.

> If the notation \\='mh-last-destination-folder' is a more modern way
> to write `mh-last-destination-folder`, then I'd stick with the \\='
> symbol you used.

I think I got confused about the quoting conventions.  After rereading
the documentation guidelines in Info, I've changed it to a backtick.
It's now

  "Refile (output) thread into FOLDER.
In a program, update the variables `mh-last-destination' and
`mh-last-destination-folder' unless DONT-UPDATE-LAST-DESTINATION-FLAG is
non-nil."

> I'd also remove the extra space after folder in mh-thread-refile:
> 
>     (folder  &optional dont-update-last-destination-flag)

Fixed (well spotted).

I've attached the revised patch#2; the first and third patches are the
same as before.

thanks,
mike

Re: draft patch set for SF#473 fix (remember dest with thread refile)

[Bill W. <wo...@ne...>]

Cool.

Now you're up to 4 :-).

Henrique Martins <mh-...@ma...> wrote:

> > Finally, the 15 lines is cumulative. Henrique, how many lines do you think you have submitted to Emacs?
> 
> Zero :-)
> 
> -- Henrique
> 
> 
> _______________________________________________
> mh-e-devel mailing list
> mh-...@li...
> https://lists.sourceforge.net/lists/listinfo/mh-e-devel
> 

-- 
Bill Wohler <wo...@ne...> aka <Bil...@na...>
http://www.newt.com/wohler/, GnuPG ID:610BD9AD

Re: draft patch set for SF#473 fix (remember dest with thread refile)

[Henrique M. <mh-...@ma...>]

> Finally, the 15 lines is cumulative. Henrique, how many lines do you think you have submitted to Emacs?

Zero :-)

-- Henrique

Re: localized dates

[Mike K. <ku...@ra...>]

Bill Wohler via mh-e-users wrote:

> How about a hook that allows the munging of header fields without the
> read-only mode annoyance, but provide at least one hook function to add
> a local time zone if needed? If there aren't any objections, I'd even
> add that hook function as the default since it seems very useful with
> little or no downside.

That all sounds fine to me.

mike

Re: localized dates

[Bill W. <wo...@ne...>]

Mike Kupfer <ku...@ra...> wrote:

> Bill Wohler via mh-e-users wrote:
> 
> > Mike Kupfer <ku...@ra...> wrote:
> 
> > > A feature request sounds fine.  If nothing else, it provides a standard
> > > place to record discussion and decisions.
> > 
> > We may be getting into the realm of mh-e-devel. At work, we can't commit
> > code without an issue. See also Tickets in The MH-E Developers Guide
> > [1]. I don't think we've been too strict about creating a ticket for all
> > code, have we?
> 
> No, I don't think we've been strict at all.  Mailing list discussion
> (either here or on mh-e-devel) also provides a record, at least as long
> as we transfer the old archives when we eventually move the lists to
> gnu.org.  But it can be harder to find the discussion from the changelog
> comments, since there's no bug number to tie the discussion to the code
> change.

Yep. I guess in this case, it would be worthwhile to annotate the commit
log to say, See mh-e-users "localized dates" discussion on 2026-03-06.

> > What sort of a hook did you have in mind? Or would the addition of the
> > local time be a boolean option you could turn on (or off if we make the
> > default on)?
> 
> I was thinking (in very fuzzy terms) of a hook that would provide a
> general way for the user to customize the presentation of headers.  I
> suppose mh-show-hook could be used in a pinch, though it seems less than
> ideal (e.g., the hook function would have to disable read-only mode).
> 
> An option that supports a limited number of ways to render the date
> would also work.

How about a hook that allows the munging of header fields without the
read-only mode annoyance, but provide at least one hook function to add
a local time zone if needed? If there aren't any objections, I'd even
add that hook function as the default since it seems very useful with
little or no downside.

> > It occurs to me that we'd only add the local time if the Date in the
> > mail header has a different time zone.
> 
> That makes sense.  We'll also need to decide what to do if the date
> string can't be parsed.  (Bail out, perhaps with an entry in the "*MH-E
> Log*" buffer, I guess.) Here are a few date strings from old emails in
> my files:
> 
>   17 Oct 1984 1059-PDT (Wednesday)
>   Wed, 17 Oct 1984 10:59 PDT
>   Wed 6 Feb 85 20:07:55-EST
>   27 Feb 85 05:32:00 GMT

Agreed on the "bail out quietly and log" solution.

-- 
Bill Wohler <wo...@ne...> aka <Bil...@na...>
http://www.newt.com/wohler/, GnuPG ID:610BD9AD

Re: localized dates

[Mike K. <ku...@ra...>]

Bill Wohler via mh-e-users wrote:

> Mike Kupfer <ku...@ra...> wrote:

> > A feature request sounds fine.  If nothing else, it provides a standard
> > place to record discussion and decisions.
> 
> We may be getting into the realm of mh-e-devel. At work, we can't commit
> code without an issue. See also Tickets in The MH-E Developers Guide
> [1]. I don't think we've been too strict about creating a ticket for all
> code, have we?

No, I don't think we've been strict at all.  Mailing list discussion
(either here or on mh-e-devel) also provides a record, at least as long
as we transfer the old archives when we eventually move the lists to
gnu.org.  But it can be harder to find the discussion from the changelog
comments, since there's no bug number to tie the discussion to the code
change.

> What sort of a hook did you have in mind? Or would the addition of the
> local time be a boolean option you could turn on (or off if we make the
> default on)?

I was thinking (in very fuzzy terms) of a hook that would provide a
general way for the user to customize the presentation of headers.  I
suppose mh-show-hook could be used in a pinch, though it seems less than
ideal (e.g., the hook function would have to disable read-only mode).

An option that supports a limited number of ways to render the date
would also work.

> It occurs to me that we'd only add the local time if the Date in the
> mail header has a different time zone.

That makes sense.  We'll also need to decide what to do if the date
string can't be parsed.  (Bail out, perhaps with an entry in the "*MH-E
Log*" buffer, I guess.) Here are a few date strings from old emails in
my files:

  17 Oct 1984 1059-PDT (Wednesday)
  Wed, 17 Oct 1984 10:59 PDT
  Wed 6 Feb 85 20:07:55-EST
  27 Feb 85 05:32:00 GMT

mike

Re: localized dates

[Bill W. <wo...@ne...>]

Mike Kupfer <ku...@ra...> wrote:

> Bill Wohler via mh-e-users wrote:
> 
> > If Mike doesn't have an objection, I'd suggest calling `M-x
> > report-emacs-bug' and making a feature request. 
> 
> A feature request sounds fine.  If nothing else, it provides a standard
> place to record discussion and decisions.

We may be getting into the realm of mh-e-devel. At work, we can't commit
code without an issue. See also Tickets in The MH-E Developers Guide
[1]. I don't think we've been too strict about creating a ticket for all
code, have we?

1. https://mh-e.sourceforge.io/doc/devguide.html#Tickets

> I'm not sure what I think about MH-E unilaterally changing the display
> of a header field like that.  My initial reaction is that this sort of
> thing would be better handled by a new hook.  On the other hand, I
> suppose that having a single, standardized treatment for "Date" would
> let us easily display the local and original times using different
> faces, and I can see value in that.

Good point, even though Evolution unilaterally does it, and doing so
doesn't seem to violate any rules that I could find.

What sort of a hook did you have in mind? Or would the addition of the
local time be a boolean option you could turn on (or off if we make the
default on)?

If anyone out there has a strong feeling about this, please let us know.
Would you prefer to see MH-E unilaterally add the local time, make it
optional initially turned on, or make it optional initially turned off?

It occurs to me that we'd only add the local time if the Date in the
mail header has a different time zone.

-- 
Bill Wohler <wo...@ne...> aka <Bil...@na...>
http://www.newt.com/wohler/, GnuPG ID:610BD9AD

Re: localized dates

[Mike K. <ku...@ra...>]

Bill Wohler via mh-e-users wrote:

> If Mike doesn't have an objection, I'd suggest calling `M-x
> report-emacs-bug' and making a feature request. 

A feature request sounds fine.  If nothing else, it provides a standard
place to record discussion and decisions.

I'm not sure what I think about MH-E unilaterally changing the display
of a header field like that.  My initial reaction is that this sort of
thing would be better handled by a new hook.  On the other hand, I
suppose that having a single, standardized treatment for "Date" would
let us easily display the local and original times using different
faces, and I can see value in that.

mike

Re: localized dates

[Bill W. <wo...@ne...>]

Michael Richardson <mc...@sa...> wrote:

> Bill Wohler <wo...@ne...> wrote:
>     > Again, I refer you to the MH-E manual[1] to learn how to change
>     > `mh-mhl-format-file' to have MH-E use mhl to render messages. You'll
> 
> understood.
> 
>     > 1. https://mh-e.sourceforge.io/manual/mh-e.html#Viewing
> 
> So, I now understand that MH-E normally does all the work itself, but it can
> use mhl.  I didn't know it could do that.  I remember some point when GNUS
> brought us all the nice mime decoding, and I think we have leveraged that since.

That sounds right.

> How does this affect rendering preferences? I would expect that now
> I have to have mhl do all the plain vs html vs show imagines and going out to
> programs itself?

I don't have any evidence that I've used mhl for over 20 years. The
manual contains the extent of my experience with it in the 90s. Good
luck on this little trip.

> Thus, I will not be able to click on a PDF attachment and see it inline
> (yeah, that only works for Emacs/X).
> Any X-windows needing mailcap things will get confused when I access my
> email (as I am right now) via ssh/mosh + emacsclient (-nw).
> This mhl solution seems to have many downsides, compared to coping with
> emails with UTC dates.
> 
> I am I thinking that I might prefer to just hack the mh-e code itself.
> Maybe it's really in MML.   I'll try the mhl path first though.

Take a look at mh-display-msg in mh-show.el. It looks like there might
be an appropriate place to edit the Date header field there.

I would not be opposed to updating the Date header field that MH-E
displays per my example.

If Mike doesn't have an objection, I'd suggest calling `M-x
report-emacs-bug' and making a feature request. Mike and I can work with
you to fold your work into MH-E. I suspect this will be a "tiny change"
(< 15 lines) and therefore won't need you to sign papers with the FSF,
but do remind us if you have already done so.

> } Normally MH-E takes care of displaying messages itself (rather than calling
> } an MH program to do the work). If you’d rather have mhl display the message
> } (within MH-E), change the option mh-mhl-format-file from its default value of
> } ‘Use Default mhl Format (Printing Only)’. You can set this option to ‘Use
> } Default mhl Format’ to get the same output as you would get if you ran mhl
> } from the shell. If you have a format file that you want MH-E to use, you can
> } set this option to ‘Specify an mhl Format File’ and enter the name of your
> } format file (mhl(1) or section Using mhl in the MH book tells you how to
> } write one). Your format file should specify a non-zero value for
> } ‘overflowoffset’ to allow MH-E to parse the header. Note that mhl is always
> } used for printing and forwarding; in this case, the value of
> } mh-mhl-format-file is consulted if you have specified a format file.
> 
> _______________________________________________
> mh-e-users mailing list
> mh-...@li...
> https://lists.sourceforge.net/lists/listinfo/mh-e-users

-- 
Bill Wohler <wo...@ne...> aka <Bil...@na...>
http://www.newt.com/wohler/, GnuPG ID:610BD9AD

Re: localized dates

[Michael R. <mc...@sa...>]

Bill Wohler <wo...@ne...> wrote:
    > Again, I refer you to the MH-E manual[1] to learn how to change
    > `mh-mhl-format-file' to have MH-E use mhl to render messages. You'll

understood.

    > 1. https://mh-e.sourceforge.io/manual/mh-e.html#Viewing

So, I now understand that MH-E normally does all the work itself, but it can
use mhl.  I didn't know it could do that.  I remember some point when GNUS
brought us all the nice mime decoding, and I think we have leveraged that since.

How does this affect rendering preferences? I would expect that now
I have to have mhl do all the plain vs html vs show imagines and going out to
programs itself?

Thus, I will not be able to click on a PDF attachment and see it inline
(yeah, that only works for Emacs/X).
Any X-windows needing mailcap things will get confused when I access my
email (as I am right now) via ssh/mosh + emacsclient (-nw).
This mhl solution seems to have many downsides, compared to coping with
emails with UTC dates.

I am I thinking that I might prefer to just hack the mh-e code itself.
Maybe it's really in MML.   I'll try the mhl path first though.

} Normally MH-E takes care of displaying messages itself (rather than calling
} an MH program to do the work). If you’d rather have mhl display the message
} (within MH-E), change the option mh-mhl-format-file from its default value of
} ‘Use Default mhl Format (Printing Only)’. You can set this option to ‘Use
} Default mhl Format’ to get the same output as you would get if you ran mhl
} from the shell. If you have a format file that you want MH-E to use, you can
} set this option to ‘Specify an mhl Format File’ and enter the name of your
} format file (mhl(1) or section Using mhl in the MH book tells you how to
} write one). Your format file should specify a non-zero value for
} ‘overflowoffset’ to allow MH-E to parse the header. Note that mhl is always
} used for printing and forwarding; in this case, the value of
} mh-mhl-format-file is consulted if you have specified a format file.

Re: localized dates

[Bill W. <wo...@ne...>]

I found the example. Here is the syntax that Evolution uses. It's
similar to the format you proposed, but it uses parens instead of curly
braces. I'd suggest using parens unless you find more examples using
curly braces.

    Date:	Wed, 04 Mar 2026 16:40:56 +0000 (2026-03-04 08:40:56)

Why am I using Evolution and not MH-E at work? NASA cut off IMAP access
years ago to take a stronger security posture using PIV cards for
authentication. Fortunately, they permit the exchange backend so I can
use Evolution on my Linux workstation instead of Look Out on the web.

Michael Richardson <mc...@sa...> wrote:

> --------
> 
> Bill Wohler <wo...@ne...> wrote:
>     >> I wonder what I'll break if I turn this into:
>     >>
>     >> Date: Sun, 1 Mar 2026 22:59:32 +0000 {2026-03-01 17:59:32 EST}
> 
>     > I've seen a MUA provide both the sender and local time in a similar way.
>     > I really, really like it. I'll see if I can dredge up a sample to give
>     > you some prior art.
> 
> Yes, if this was all GUI, I'd definitely want to pick local/sender value,
> with the opposite (or maybe both) being displayed when one hovers...
> Not at all what I want inside emacs.
> 
>     > As long as you don't transmit that non-standard Date header field you
>     > should be fine. You can view it however you wish.
> 
> :-)
> 
> --
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
> ]     mc...@sa...  http://www.sandelman.ca/        |   ruby on rails    [
> 
> 
> _______________________________________________
> mh-e-users mailing list
> mh-...@li...
> https://lists.sourceforge.net/lists/listinfo/mh-e-users
> 

-- 
Bill Wohler <wo...@ne...> aka <Bil...@na...>
http://www.newt.com/wohler/, GnuPG ID:610BD9AD

Re: localized dates

[Bill W. <wo...@ne...>]

Again, I refer you to the MH-E manual[1] to learn how to change
`mh-mhl-format-file' to have MH-E use mhl to render messages. You'll
then want to read the mhl man page to learn out to write your mhl format
file. I believe I sent my old version already that you can use as a
starting point.

1. https://mh-e.sourceforge.io/manual/mh-e.html#Viewing

Michael Richardson <mc...@sa...> wrote:

> 
> mh-format includes:
>           date2local() function
> which is exactly what I want, assuming it can be accessed at the right time.
> (I already have a custom scan that shows me List-Id: and/or spam results)
> 
> I'm still uncertain about what format I would use/edit.
> Does mh-e actually invoke mhl or some showproc to display/render the message?
> If so, then I can edit the formfile.
> 
> --
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
> ]     mc...@sa...  http://www.sandelman.ca/        |   ruby on rails    [
> 
> 
> 
> _______________________________________________
> mh-e-users mailing list
> mh-...@li...
> https://lists.sourceforge.net/lists/listinfo/mh-e-users

-- 
Bill Wohler <wo...@ne...> aka <Bil...@na...>
http://www.newt.com/wohler/, GnuPG ID:610BD9AD

Re: localized dates

[Michael R. <mc...@sa...>]

mh-format includes:
          date2local() function
which is exactly what I want, assuming it can be accessed at the right time.
(I already have a custom scan that shows me List-Id: and/or spam results)

I'm still uncertain about what format I would use/edit.
Does mh-e actually invoke mhl or some showproc to display/render the message?
If so, then I can edit the formfile.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mc...@sa...  http://www.sandelman.ca/        |   ruby on rails    [

Re: localized dates

[Michael R. <mc...@sa...>]

--------

Bill Wohler <wo...@ne...> wrote:
    >> I wonder what I'll break if I turn this into:
    >>
    >> Date: Sun, 1 Mar 2026 22:59:32 +0000 {2026-03-01 17:59:32 EST}

    > I've seen a MUA provide both the sender and local time in a similar way.
    > I really, really like it. I'll see if I can dredge up a sample to give
    > you some prior art.

Yes, if this was all GUI, I'd definitely want to pick local/sender value,
with the opposite (or maybe both) being displayed when one hovers...
Not at all what I want inside emacs.

    > As long as you don't transmit that non-standard Date header field you
    > should be fine. You can view it however you wish.

:-)

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mc...@sa...  http://www.sandelman.ca/        |   ruby on rails    [

Re: localized dates

[Bill W. <wo...@ne...>]

Michael Richardson <mc...@sa...> wrote:

> 
>     > I'm pretty sure the Date field is written in the time zone of the
>     > sender. It's useful to know whether the sender sent the email after his
>     > or her coffee or after his or her last glass of wine.
> 
> Yes, I agree it's useful to know what time it was for them.
> But, the hosted environments like outlook.com don't seem to do that, putting
> everything in GMT.
> 
>     > I'm hoping that the sender of that message was around GMT.
> 
> Yes.
> 
>     > That said, there is probably some MH magic you could add to one of your
>     > MH format files to display the Date header field in *your* localtime.
>     > The man page for mh-format indicates that the date2local function might
> 
> Yeah, okay.  I could change nmh's mh-format to do what I want.
> I guess I wasn't thinking that mh-e actually went through that.
> 
> I wonder what I'll break if I turn this into:
> 
>    Date: Sun, 1 Mar 2026 22:59:32 +0000 {2026-03-01 17:59:32 EST}

I've seen a MUA provide both the sender and local time in a similar way.
I really, really like it. I'll see if I can dredge up a sample to give
you some prior art.

As long as you don't transmit that non-standard Date header field you
should be fine. You can view it however you wish.

> 
> Or, I guess I could try to add:
>    LocalDate: 2026-03-01 17:59:32 EST
> 
> or:
>    LocalDate: OTTAWA 2026-03-01 17:59:32 EST
> 
>     > be the ticket. Otherwise, nmh...@no... might be a good source
>     > for info.
> 
> Already there :-)
> 
> --
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
> ]     mc...@sa...  http://www.sandelman.ca/        |   ruby on rails    [
> 
> _______________________________________________
> mh-e-users mailing list
> mh-...@li...
> https://lists.sourceforge.net/lists/listinfo/mh-e-users

-- 
Bill Wohler <wo...@ne...> aka <Bil...@na...>
http://www.newt.com/wohler/, GnuPG ID:610BD9AD

Re: localized dates

[Michael R. <mc...@sa...>]

    > I'm pretty sure the Date field is written in the time zone of the
    > sender. It's useful to know whether the sender sent the email after his
    > or her coffee or after his or her last glass of wine.

Yes, I agree it's useful to know what time it was for them.
But, the hosted environments like outlook.com don't seem to do that, putting
everything in GMT.

    > I'm hoping that the sender of that message was around GMT.

Yes.

    > That said, there is probably some MH magic you could add to one of your
    > MH format files to display the Date header field in *your* localtime.
    > The man page for mh-format indicates that the date2local function might

Yeah, okay.  I could change nmh's mh-format to do what I want.
I guess I wasn't thinking that mh-e actually went through that.

I wonder what I'll break if I turn this into:

   Date: Sun, 1 Mar 2026 22:59:32 +0000 {2026-03-01 17:59:32 EST}

Or, I guess I could try to add:
   LocalDate: 2026-03-01 17:59:32 EST

or:
   LocalDate: OTTAWA 2026-03-01 17:59:32 EST

    > be the ticket. Otherwise, nmh...@no... might be a good source
    > for info.

Already there :-)

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mc...@sa...  http://www.sandelman.ca/        |   ruby on rails    [

Re: localized dates

[Bill W. <wo...@ne...>]

Regarding mhl, please see [1] and look for the paragraph starting with
"Normally MH-E takes care of displaying messages itself..." about 13
paragraphs down.

1. https://mh-e.sourceforge.io/manual/mh-e.html#Viewing

Heh heh, although I don't currently use mhl for showing my mail,
apparently I did once as I have a mhl.format file in my MH mail
directory. Note what I have for the Date header field. I also note this
file is different from that in /etc/nmh.

    [wohler@olgas mail (olgas:*)]$ less mhl.format 
    overflowtext="***",overflowoffset=5
    width=1024,leftadjust,compwidth=9
    ignores=msgid,message-id,received,content-type,content-transfer-encoding,content-id
    ignores=received-by,received-date
    ignores=via,mail-from,return-path,>From,delivery-date,status,sender,reply-to
    ignores=replied,forwarded,resent-from,resent-to,resent-message-id,resent-date
    ignores=path,references,lines
    ignores=mime-version,ignores=content-length,content-description
    Date:formatfield="%<(nodate{text})%{text}%|%(date2local{text})%(pretty{text})%>"
    To:
    cc:
    From:decode
    Subject:decode
    :
    extras:nocomponent
    :
    body:nocomponent,overflowtext=,overflowoffset=0,noleftadjust


Mike Kupfer <ku...@ra...> wrote:

> Bill Wohler via mh-e-users wrote:
> 
> > I'm pretty sure the Date field is written in the time zone of the
> > sender. It's useful to know whether the sender sent the email after his
> > or her coffee or after his or her last glass of wine.
> 
> I get a surprising number of emails that have a UTC Date field.  Some of
> them do appear to be from people in the UK, but quite a few are bulk
> emails (vendor newsletters, Nextdoor updates, etc).
> 
> > That said, there is probably some MH magic you could add to one of your
> > MH format files to display the Date header field in *your* localtime.
> > The man page for mh-format indicates that the date2local function might
> > be the ticket. 
> 
> IIUC, you can tell MH-E to use mhl to display a message, and you can
> configure mhl to reformat the date into local time.  But I've never
> worked out the details.
> 
> mike
> 
> 
> _______________________________________________
> mh-e-users mailing list
> mh-...@li...
> https://lists.sourceforge.net/lists/listinfo/mh-e-users
> 

-- 
Bill Wohler <wo...@ne...> aka <Bil...@na...>
http://www.newt.com/wohler/, GnuPG ID:610BD9AD

Re: localized dates

[Mike K. <ku...@ra...>]

Bill Wohler via mh-e-users wrote:

> I'm pretty sure the Date field is written in the time zone of the
> sender. It's useful to know whether the sender sent the email after his
> or her coffee or after his or her last glass of wine.

I get a surprising number of emails that have a UTC Date field.  Some of
them do appear to be from people in the UK, but quite a few are bulk
emails (vendor newsletters, Nextdoor updates, etc).

> That said, there is probably some MH magic you could add to one of your
> MH format files to display the Date header field in *your* localtime.
> The man page for mh-format indicates that the date2local function might
> be the ticket. 

IIUC, you can tell MH-E to use mhl to display a message, and you can
configure mhl to reformat the date into local time.  But I've never
worked out the details.

mike

Re: localized dates

[Henrique M. <mh-...@ma...>]

%>\
mhical.12hourmhical.24hourmhical.24hour
-- Henrique