mh-e-devel — Forum for MH-E developers.

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

[mh-e:bugs] #473 mh-refile-msg vs mh-thread-refile

[Mike K. <mk...@us...>]

- **status**: open --> closed-fixed



---

**[bugs:#473] mh-refile-msg vs mh-thread-refile**

**Status:** closed-fixed
**Milestone:** Unassigned
**Labels:** patch 
**Created:** Fri May 10, 2013 12:41 PM UTC by Henrique Martins
**Last Updated:** Fri Apr 10, 2026 06:23 PM UTC
**Owner:** Mike Kupfer


Seems that
  mh-refile-msg
sets the variables
  mh-last-destination
and
  mh-last-destination-folder
to be used in future refiles, but
  mh-thread-refile
does not sets those thus things can get a bit confusing if one does a few of each in succession.

Shouldn't the behavior be identical?



---

Sent from sourceforge.net because mh-...@li... is subscribed to https://sourceforge.net/p/mh-e/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/mh-e/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[mh-e:bugs] #473 mh-refile-msg vs mh-thread-refile

[Mike K. <mk...@us...>]

The fix will appear in Emacs 31; commits b07a3970ae, 80c0529e94, and bc0eacca97.


---

**[bugs:#473] mh-refile-msg vs mh-thread-refile**

**Status:** open
**Milestone:** Unassigned
**Labels:** patch 
**Created:** Fri May 10, 2013 12:41 PM UTC by Henrique Martins
**Last Updated:** Fri Jan 16, 2026 12:18 AM UTC
**Owner:** Mike Kupfer


Seems that
  mh-refile-msg
sets the variables
  mh-last-destination
and
  mh-last-destination-folder
to be used in future refiles, but
  mh-thread-refile
does not sets those thus things can get a bit confusing if one does a few of each in succession.

Shouldn't the behavior be identical?



---

Sent from sourceforge.net because mh-...@li... is subscribed to https://sourceforge.net/p/mh-e/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/mh-e/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

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: draft patch set for SF#473 fix (remember dest with thread refile)

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

I checked the manual and mh-refile-msg doesn't refer to either
mh-last-destination or mh-last-destination-folder, so no reason to start
now.

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. 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'd also remove the extra space after folder in mh-thread-refile:

    (folder  &optional dont-update-last-destination-flag)

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

I think I'd keep the last two patches in separate commits. I don't see
any commits to MH-E-NEWS that include other files.

Otherwise, looks good to me, thanks all. 

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

> Hi, I'd like feedback on the attached 3 patches, which change
> mh-thread-refile so that it remembers the destination.
> 
> The 1st patch is what I got from Henrique.  Henrique, are you okay with
> the way I attributed the fix?
> 
> The 2nd patch addresses a compilation warning and updates the docstring.
> 
> The 3rd patch adds an entry to MH-E-NEWS.
> 
> I could fold the 3rd patch into the 2nd one.
> 
> I'd like to keep the 1st patch separate.  Henrique doesn't have a
> copyright assignment on file for Emacs.  I believe his patch is small
> enough not to need one, but then I don't want my changes to count
> against his contribution line limit.
> 
> Let me know what you think.
> 
> thanks,
> mike
> _______________________________________________
> 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

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

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

Hi, I'd like feedback on the attached 3 patches, which change
mh-thread-refile so that it remembers the destination.

The 1st patch is what I got from Henrique.  Henrique, are you okay with
the way I attributed the fix?

The 2nd patch addresses a compilation warning and updates the docstring.

The 3rd patch adds an entry to MH-E-NEWS.

I could fold the 3rd patch into the 2nd one.

I'd like to keep the 1st patch separate.  Henrique doesn't have a
copyright assignment on file for Emacs.  I believe his patch is small
enough not to need one, but then I don't want my changes to count
against his contribution line limit.

Let me know what you think.

thanks,
mike

Re: etc/NEWS vs etc/MH-E-NEWS

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

Sounds good.  I'll try to have a patch for review for SF#473 in the next
couple weeks.

mike

Bill Wohler via mh-e-devel wrote:

> Thanks, Mike. Sounds like we should go with the status quo (MH-E-NEWS) then.
> 
> Let's think to update the file when we resolve issues.
> 
> Since we no longer have MH-E releases, we should use headings based upon
> Emacs releases in the future.
> 
> Mike Kupfer <ku...@ra...> wrote:
> 
> > Mike Kupfer wrote:
> > 
> > > Bill Wohler wrote:
> > 
> > > > More important, what do our users think?
> > > 
> > > Indeed.  I'll send a note to mh-e-users and see if anyone there has an
> > > opinion.
> > 
> > Well, after a week I've gotten 2 responses.  One was to continue using
> > MH-E-NEWS, perhaps with the addition of adding a line in NEWS to refer
> > people to MH-E-NEWS.  (Personally, I think that adds unnecessary clutter
> > to NEWS, especially since the MH-E Manual already mentions MH-E-NEWS.
> > Though I expect that the wording in the MH-E Manual could use some
> > tweaking.)
> > 
> > The other response was a dont-care.  ("In my 30+ years of Emacs/Xemacs
> > usage don't think I read some NEWS page more than a couple of times.")
> > 
> > I'm fine with continuing to use MH-E-NEWS, if that's your preference.
> > 
> > mike
> > 
> > 
> > _______________________________________________
> > 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: etc/NEWS vs etc/MH-E-NEWS

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

Thanks, Mike. Sounds like we should go with the status quo (MH-E-NEWS) then.

Let's think to update the file when we resolve issues.

Since we no longer have MH-E releases, we should use headings based upon
Emacs releases in the future.

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

> Mike Kupfer wrote:
> 
> > Bill Wohler wrote:
> 
> > > More important, what do our users think?
> > 
> > Indeed.  I'll send a note to mh-e-users and see if anyone there has an
> > opinion.
> 
> Well, after a week I've gotten 2 responses.  One was to continue using
> MH-E-NEWS, perhaps with the addition of adding a line in NEWS to refer
> people to MH-E-NEWS.  (Personally, I think that adds unnecessary clutter
> to NEWS, especially since the MH-E Manual already mentions MH-E-NEWS.
> Though I expect that the wording in the MH-E Manual could use some
> tweaking.)
> 
> The other response was a dont-care.  ("In my 30+ years of Emacs/Xemacs
> usage don't think I read some NEWS page more than a couple of times.")
> 
> I'm fine with continuing to use MH-E-NEWS, if that's your preference.
> 
> mike
> 
> 
> _______________________________________________
> 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: etc/NEWS vs etc/MH-E-NEWS

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

Mike Kupfer wrote:

> Bill Wohler wrote:

> > More important, what do our users think?
> 
> Indeed.  I'll send a note to mh-e-users and see if anyone there has an
> opinion.

Well, after a week I've gotten 2 responses.  One was to continue using
MH-E-NEWS, perhaps with the addition of adding a line in NEWS to refer
people to MH-E-NEWS.  (Personally, I think that adds unnecessary clutter
to NEWS, especially since the MH-E Manual already mentions MH-E-NEWS.
Though I expect that the wording in the MH-E Manual could use some
tweaking.)

The other response was a dont-care.  ("In my 30+ years of Emacs/Xemacs
usage don't think I read some NEWS page more than a couple of times.")

I'm fine with continuing to use MH-E-NEWS, if that's your preference.

mike

Re: etc/NEWS vs etc/MH-E-NEWS

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

Bill Wohler wrote:

> Let's think about this along with the output of M-x mh-version,

Good point.  I like the format that you suggested.

> I'm thinking we could go in one of two ways.
> 
> 1. Add the following to MH-E-NEWS before the existing "* Changes in MH-E
>    8.6" entry:
> 
>    * MH-E changes now documented in the main Emacs NEWS file.
>    
>    and then document changes in NEWS like other packages.
> 
> 2. Continue documenting changes in MH-E-NEWS and change the next
>    heading, for example, to
> 
>    * Changes in MH-E in GNU Emacs 31.1
> 
> It looks like CALC-NEWS ("For changes in Emacs 23.1 and later, see the
> main Emacs NEWS file.") and NXML-NEWS ("For more recent changes, see the
> main Emacs NEWS file.") went with option 1 and EGLOT-NEWS and ORG-NEWS
> went with option 2.

I don't know how Calc, NXML, and Eglot development is currently managed.
Org mode development happens in a separate repo, and then new versions
get folded into Emacs.  The separate ORG-NEWS file is a good match for
that workflow, because entries can be added as changes are made in the
upstream repo, and then it's just a matter of dropping the updated
ORG-NEWS into the Emacs repo.

If we think that someday there might once again be standalone MH-E
releases, then continuing to update MH-E-NEWS makes sense to me.
Otherwise, I think it makes more sense to add updates to NEWS, while
keeping the old MH-E-NEWS file around for history (i.e., follow the Calc
and NXML model).  But it's not something I feel strongly about.

> More important, what do our users think?

Indeed.  I'll send a note to mh-e-users and see if anyone there has an
opinion.

thanks,
mike

Re: etc/NEWS vs etc/MH-E-NEWS

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

Great question, and thanks for the fix!

Let's think about this along with the output of M-x mh-version, which is
currently:

    MH-E 8.6+git

    MH-E compilation details:
     Compiled:		yes
     Gnus (compile-time):	Gnus v5.13
     Gnus (run-time):	Gnus v5.13

    GNU Emacs 31.0.50 (build 5, x86_64-pc-linux-gnu, GTK+ Version 3.24.51, cairo version 1.18.4)
     of 2026-02-14

    nmh 1.8
     mh-progs:	/usr/bin/mh
     mh-lib:	/etc/nmh
     mh-lib-progs:	/usr/lib/mh

    Linux olgas 6.18.9+deb14-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.18.9-1 (2026-02-07) x86_64 GNU/Linux

This should probably be changed to something like:

    MH-E in GNU Emacs 31.0.50 (build 5, x86_64-pc-linux-gnu, GTK+
     Version 3.24.51, cairo version 1.18.4) of 2026-02-14

    MH-E compilation details:
     Compiled:		yes
     Gnus (compile-time):	Gnus v5.13
     Gnus (run-time):	Gnus v5.13

    nmh 1.8
     mh-progs:	/usr/bin/mh
     mh-lib:	/etc/nmh
     mh-lib-progs:	/usr/lib/mh

    Linux olgas 6.18.9+deb14-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.18.9-1 (2026-02-07) x86_64 GNU/Linux

I'm thinking we could go in one of two ways.

1. Add the following to MH-E-NEWS before the existing "* Changes in MH-E
   8.6" entry:

   * MH-E changes now documented in the main Emacs NEWS file.
   
   and then document changes in NEWS like other packages.

2. Continue documenting changes in MH-E-NEWS and change the next
   heading, for example, to

   * Changes in MH-E in GNU Emacs 31.1

It looks like CALC-NEWS ("For changes in Emacs 23.1 and later, see the
main Emacs NEWS file.") and NXML-NEWS ("For more recent changes, see the
main Emacs NEWS file.") went with option 1 and EGLOT-NEWS and ORG-NEWS
went with option 2.

Although there's a nice continuity keeping the changes in MH-E-NEWS,
there seems to be some precedent to move the news to NEWS.

It seems that option 2 would have benefited your recent forensics by
keeping all of the MH-E changes together.

I'm very torn. I have an affinity for option 2, but might be talked into
option 1. What do you think? More important, what do our users think? Is
it more important to keep the changes with other Emacs changes or other
MH-E changes?

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

> I drafted a NEWS entry for Henrique's fix to mh-thread-refile (SF#473),
> but I'm not sure where to put it.
> 
> The top-level entries in MH-E-NEWS are for MH-E releases, but we're no
> longer doing standalone MH-E releases.  Do we want to keep using
> MH-E-NEWS and add top-level entries for Emacs releases?  Or do we want
> to start documenting changes in NEWS?  If we start using NEWS, what
> should we do with MH-E-NEWS?
> 
> mike

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

etc/NEWS vs etc/MH-E-NEWS

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

I drafted a NEWS entry for Henrique's fix to mh-thread-refile (SF#473),
but I'm not sure where to put it.

The top-level entries in MH-E-NEWS are for MH-E releases, but we're no
longer doing standalone MH-E releases.  Do we want to keep using
MH-E-NEWS and add top-level entries for Emacs releases?  Or do we want
to start documenting changes in NEWS?  If we start using NEWS, what
should we do with MH-E-NEWS?

mike

[mh-e:bugs] #473 mh-refile-msg vs mh-thread-refile

[Mike K. <mk...@us...>]

- **assigned_to**: Mike Kupfer



---

**[bugs:#473] mh-refile-msg vs mh-thread-refile**

**Status:** open
**Milestone:** Unassigned
**Labels:** patch 
**Created:** Fri May 10, 2013 12:41 PM UTC by Henrique Martins
**Last Updated:** Sat Nov 21, 2020 03:47 AM UTC
**Owner:** Mike Kupfer


Seems that
  mh-refile-msg
sets the variables
  mh-last-destination
and
  mh-last-destination-folder
to be used in future refiles, but
  mh-thread-refile
does not sets those thus things can get a bit confusing if one does a few of each in succession.

Shouldn't the behavior be identical?



---

Sent from sourceforge.net because mh-...@li... is subscribed to https://sourceforge.net/p/mh-e/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/mh-e/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

oddballs headers (was: mh-delay-invisible-header-generation-flag unused?)

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

Greg Minshall wrote:

> Bill,
> 
> just on this bit ...
> 
> > > there *is* this category of header like something in your (and others')
> > > mail path,
> > > ----
> > > X-Celery-Duck: 0ed3c38155a6e12f_1746628670922_1189935157
> > > ----
> > 
> > I just sent myself a message and did not see this header field nor
> > X-Ski-Harbor that you mentioned earlier, nor do I recall having ever
> > seen them.
> 
> i don't remember if i ever figured out where such come from.  *this*
> message of yours i'm replying to came with
> > X-Abortive-Chemical: 7d31a6c32f1fe7d6_1746672691788_3984653691
> it seems some sort of "cookie", and i think it's the rare sender that
> generates them.  the header name in each e-mail message is ("appears to
> be") unique.

Yes, I'm seeing them in Bill's emails, too.  Just in this thread, we
have

  X-Ski-Harbor: 7030ed6d041a7a69_1746499874510_3614245023
  Message-ID: <526...@ol...>
  
  X-Zesty-Eyes: 522cc1ea44fd17a2_1746540458496_4272817742
  Message-ID: <582...@ol...>
  
  X-Wide-Eyed-Trail: 6f2f0c6647f82964_1746555648730_2079165643
  Message-ID: <596...@ol...>
  
  X-Fumbling-Society: 188867321849952d_1746585188317_3138387312
  Message-ID: <623...@ol...>
  
  X-Celery-Duck: 0ed3c38155a6e12f_1746628670922_1189935157
  Message-ID: <681...@ol...>
  
  X-Abortive-Chemical: 7d31a6c32f1fe7d6_1746672691788_3984653691
  Message-ID: <738...@ol...>

(I included the message ID to indicate which message the oddball header
appeared in.)

The oddball header consistently appears in a cluster with 

  X-MC-Relay
  X-MailChannels-SenderId
  X-MailChannels-Auth-Id
  X-MC-Loop-Signature
  X-MC-Ingress-Time

So I expect that whatever is adding those headers is also adding the
oddball one.

mike

Re: mh-delay-invisible-header-generation-flag unused?

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

Bill Wohler via mh-e-devel wrote:

> I'm wondering if a better approach would be for someone (us?) to write
> some contributed software that interested folks could add to an
> appropriate mail hook. It would look at all the header fields in the
> current message and compare them to a list in a file somewhere
> (~/.emacs.d/seen-header-fields?) and display any header fields that are
> new. That way the user doesn't miss any header fields. The user doesn't
> have to take any action not to see them again (the most common case),
> but they do have to take action if they do (rarely) by adding them to
> their show-header-field option.

Interesting suggestion.  I'd be okay with that.

mike

Re: mh-delay-invisible-header-generation-flag unused?

[Greg M. <min...@um...>]

Bill,

just on this bit ...

> > there *is* this category of header like something in your (and others')
> > mail path,
> > ----
> > X-Celery-Duck: 0ed3c38155a6e12f_1746628670922_1189935157
> > ----
> 
> I just sent myself a message and did not see this header field nor
> X-Ski-Harbor that you mentioned earlier, nor do I recall having ever
> seen them.

i don't remember if i ever figured out where such come from.  *this*
message of yours i'm replying to came with
> X-Abortive-Chemical: 7d31a6c32f1fe7d6_1746672691788_3984653691
it seems some sort of "cookie", and i think it's the rare sender that
generates them.  the header name in each e-mail message is ("appears to
be") unique.

clearly there should be a "where-e-mail-header-X-added:" e-mail header.
:)

it's *not* from the mailing list, as (at least some) other senders don't
generate.

cheers, Greg

Re: mh-delay-invisible-header-generation-flag unused?

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

Greg Minshall <min...@um...> wrote:

> Bill,
> 
> > I'm wondering if a better approach would be for someone (us?) to write
> > some contributed software that interested folks could add to an
> > appropriate mail hook. It would look at all the header fields in the
> > current message and compare them to a list in a file somewhere
> > (~/.emacs.d/seen-header-fields?) and display any header fields that are
> > new. That way the user doesn't miss any header fields. The user doesn't
> > have to take any action not to see them again (the most common case),
> > but they do have to take action if they do (rarely) by adding them to
> > their show-header-field option.
> 
> my paranoia includes myself neglecting something the first N times i see
> it.

You could always review ~/.emacs.d/seen-header-fields if you have a
panic attack.

> if it were done with a "ignore X-ONE-WEIRD-MAIL-HEADER? [y,n]" (possibly
> as an option), that would work for me.

Since new header fields occur hourly, and sometimes dozens of new ones
can appear in a single message, the best scheme is one that shows you
the new header fields without requiring any interaction.

> there *is* this category of header like something in your (and others')
> mail path,
> ----
> X-Celery-Duck: 0ed3c38155a6e12f_1746628670922_1189935157
> ----

I just sent myself a message and did not see this header field nor
X-Ski-Harbor that you mentioned earlier, nor do I recall having ever
seen them.

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

Re: mh-delay-invisible-header-generation-flag unused?

[Greg M. <min...@um...>]

Bill,

> I'm wondering if a better approach would be for someone (us?) to write
> some contributed software that interested folks could add to an
> appropriate mail hook. It would look at all the header fields in the
> current message and compare them to a list in a file somewhere
> (~/.emacs.d/seen-header-fields?) and display any header fields that are
> new. That way the user doesn't miss any header fields. The user doesn't
> have to take any action not to see them again (the most common case),
> but they do have to take action if they do (rarely) by adding them to
> their show-header-field option.

my paranoia includes myself neglecting something the first N times i see
it.

if it were done with a "ignore X-ONE-WEIRD-MAIL-HEADER? [y,n]" (possibly
as an option), that would work for me.

there *is* this category of header like something in your (and others')
mail path,
----
X-Celery-Duck: 0ed3c38155a6e12f_1746628670922_1189935157
----
that comes up every time.  i somehow recognize them, and don't add them
to my list of "unwanted headers".  your scheme might "fail" there
(asking over and over).

designing online (the best idea, right? :), maybe something like TCP
implementations do to reduce DOS attacks: keep a second file, "number of
times seen", and only ask when that number grows to some cutoff
(probably even 2) would 

btw, does (or, "could") this sort of degenerate to an "invisible-header"
(whatever) scheme like we currently have, but by automatically (via the
question above) adding to the (somewhat distributed) list of unwanted
headers making it much more user friendly?

cheers, Greg

ps -- if we have the "number of times seen" cache, maybe include in each
entry the last date seen; after a year, these could be removed from the
cache.