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

Re: test email

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

Mike, fwiw, i got the same (replying to something earlier of yours?).
glad it's all well now.  cheers, Greg

Re: test email

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

Bill Wohler wrote:

> Received. ccing the list just in case I can't send either.

Thanks!

mike

Re: test email

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

Received. ccing the list just in case I can't send either.

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

> I got a bounce yesterday for something I had sent to mh-e-users.  The
> bounce message implied that there was a widespread problem with mailing
> lists, but I don't see anything mentioned at the "site status" page.
> 
> mike

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

test email

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

I got a bounce yesterday for something I had sent to mh-e-users.  The
bounce message implied that there was a widespread problem with mailing
lists, but I don't see anything mentioned at the "site status" page.

mike

Re: MH-E mailing lists at lists.gnu.org?

[Ian K. <ia...@fs...>]

Bill Wohler via <ma...@gn...> writes:

> MH-E, which is now a part of Emacs, is being slowly migrated away from
> SourceForge to gnu.org. One of the items to migrate is the mailing
> lists:
>
> mh-...@li...
> mh-...@li...
> mh-...@li...
>
> Would it be possible to create these lists on lists.gnu.org?
>
> The admins would be:
>
> Bill Wohler <wo...@ne...>
> Mike Kupfer <ku...@ra...>

Yes. Do you have mbox archives of the history I can import?

MH-E mailing lists at lists.gnu.org?

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

MH-E, which is now a part of Emacs, is being slowly migrated away from
SourceForge to gnu.org. One of the items to migrate is the mailing
lists:

mh-...@li...
mh-...@li...
mh-...@li...

Would it be possible to create these lists on lists.gnu.org?

The admins would be:

Bill Wohler <wo...@ne...>
Mike Kupfer <ku...@ra...>

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

[mh-e:bugs] #482 Incorrect usage of cl-flet

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

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



---

**[bugs:#482] Incorrect usage of cl-flet**

**Status:** closed-fixed
**Milestone:** mh-e-8.7
**Created:** Mon Jan 18, 2016 06:02 AM UTC by Bill Wohler
**Last Updated:** Sun Dec 31, 2023 03:47 AM UTC
**Owner:** Bill Wohler


Katsumi Yamaoka <ya...@jp...> submitted Emacs bug#22317: 
25.0.50; mh-e: wrong usage of cl-flet

Hi,

mh-e uses Gnus functions to render MIME messages and uses the mh-cl-flet macro to modify some of them.  Currently mh-e always loads cl (see mh-acros.el), so both cl-flet and flet are available and mh-cl-flet will become cl-flet:

    ,----
    | ;; Emacs 24 renamed flet to cl-flet.
    | (defalias 'mh-cl-flet
    |   (if (fboundp 'cl-flet)
    |       'cl-flet
    |     'flet))
    `----

However, cl-flet is quite unlike flet, IIUC.  For instance, if cl-flet is used, the mh-cl-flet code in mh-display-emphasis

    ,----
    | ;; (defun mh-display-emphasis ()
    | ;;   "Display graphical emphasis."
    | ;;   (when (and mh-graphical-emphasis-flag (mh-small-show-buffer-p))
    |        (mh-cl-flet
    |         ((article-goto-body ()))      ; shadow this function to do nothing
    |         (save-excursion
    |           (goto-char (point-min))
    |           (article-emphasize)))
    | ;;     ))
    `----

will be expanded to

    ,----
    | (progn
    |   (save-excursion
    |     (goto-char (point-min))
    |     (article-emphasize)))
    `----

whereas if flet is used, it will be expanded to:

    ,----
    | (let* ((vnew (cl-function (lambda nil
    |                           (cl-block article-goto-body))))
    |        (old (symbol-function 'article-goto-body)))
    |   (unwind-protect
    |       (progn
    |       (fset 'article-goto-body vnew)
    |       (save-excursion
    |         (goto-char (point-min))
    |         (article-emphasize)))
    |     (fset 'article-goto-body old)))
    `----

Note that the former doesn't achieve the original target, i.e.,article-goto-body is not modified while running article-emphasize.

I don't know how it damages the behavior of mh-e, but I think it should be fixed anyway.  If mh-e keeps loading cl as ever,mh-cl-flet can be:

    (defalias 'mh-cl-flet 'flet)

Otherwise use this complete Emacs-Lisp style flet emulation macro (a copy of gmm-flet that exists in only the Gnus git master):

    (defmacro mh-cl-flet (bindings &rest body)
      "Make temporary overriding function definitions.
    This is an analogue of a dynamically scoped `let' that operates on
    the function cell of FUNCs rather than their value cell.

    \(fn ((FUNC ARGLIST BODY...) ...) FORM...)"
      (require 'cl)
      (if (fboundp 'cl-letf)
          `(cl-letf ,(mapcar (lambda (binding)
                               `((symbol-function ',(car binding))
                                 (lambda ,@(cdr binding))))
                             bindings)
             ,@body)
        `(flet ,bindings ,@body)))
    (put 'mh-cl-flet 'lisp-indent-function 1)
    (put 'mh-cl-flet 'edebug-form-spec
         '((&rest (sexp sexp &rest form)) &rest form))

I'm not the right person to install it since I'm not a mh-e user,sorry.

Regards,



---

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] #482 Incorrect usage of cl-flet

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

I'm going to have to agree with Mike. We'll put the flet bug to rest unless we hear otherwise. Resolving as fixed.


---

**[bugs:#482] Incorrect usage of cl-flet**

**Status:** open
**Milestone:** mh-e-8.7
**Created:** Mon Jan 18, 2016 06:02 AM UTC by Bill Wohler
**Last Updated:** Thu Jun 22, 2017 11:30 PM UTC
**Owner:** Bill Wohler


Katsumi Yamaoka <ya...@jp...> submitted Emacs bug#22317: 
25.0.50; mh-e: wrong usage of cl-flet

Hi,

mh-e uses Gnus functions to render MIME messages and uses the mh-cl-flet macro to modify some of them.  Currently mh-e always loads cl (see mh-acros.el), so both cl-flet and flet are available and mh-cl-flet will become cl-flet:

    ,----
    | ;; Emacs 24 renamed flet to cl-flet.
    | (defalias 'mh-cl-flet
    |   (if (fboundp 'cl-flet)
    |       'cl-flet
    |     'flet))
    `----

However, cl-flet is quite unlike flet, IIUC.  For instance, if cl-flet is used, the mh-cl-flet code in mh-display-emphasis

    ,----
    | ;; (defun mh-display-emphasis ()
    | ;;   "Display graphical emphasis."
    | ;;   (when (and mh-graphical-emphasis-flag (mh-small-show-buffer-p))
    |        (mh-cl-flet
    |         ((article-goto-body ()))      ; shadow this function to do nothing
    |         (save-excursion
    |           (goto-char (point-min))
    |           (article-emphasize)))
    | ;;     ))
    `----

will be expanded to

    ,----
    | (progn
    |   (save-excursion
    |     (goto-char (point-min))
    |     (article-emphasize)))
    `----

whereas if flet is used, it will be expanded to:

    ,----
    | (let* ((vnew (cl-function (lambda nil
    |                           (cl-block article-goto-body))))
    |        (old (symbol-function 'article-goto-body)))
    |   (unwind-protect
    |       (progn
    |       (fset 'article-goto-body vnew)
    |       (save-excursion
    |         (goto-char (point-min))
    |         (article-emphasize)))
    |     (fset 'article-goto-body old)))
    `----

Note that the former doesn't achieve the original target, i.e.,article-goto-body is not modified while running article-emphasize.

I don't know how it damages the behavior of mh-e, but I think it should be fixed anyway.  If mh-e keeps loading cl as ever,mh-cl-flet can be:

    (defalias 'mh-cl-flet 'flet)

Otherwise use this complete Emacs-Lisp style flet emulation macro (a copy of gmm-flet that exists in only the Gnus git master):

    (defmacro mh-cl-flet (bindings &rest body)
      "Make temporary overriding function definitions.
    This is an analogue of a dynamically scoped `let' that operates on
    the function cell of FUNCs rather than their value cell.

    \(fn ((FUNC ARGLIST BODY...) ...) FORM...)"
      (require 'cl)
      (if (fboundp 'cl-letf)
          `(cl-letf ,(mapcar (lambda (binding)
                               `((symbol-function ',(car binding))
                                 (lambda ,@(cdr binding))))
                             bindings)
             ,@body)
        `(flet ,bindings ,@body)))
    (put 'mh-cl-flet 'lisp-indent-function 1)
    (put 'mh-cl-flet 'edebug-form-spec
         '((&rest (sexp sexp &rest form)) &rest form))

I'm not the right person to install it since I'm not a mh-e user,sorry.

Regards,



---

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] #494 mh-funcall-if-exists ignores function if it wasn't there at compile time

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

Fixed in a058d61615.


---

**[bugs:#494] mh-funcall-if-exists ignores function if it wasn't there at compile time**

**Status:** closed-fixed
**Milestone:** Unassigned
**Created:** Mon Jan 20, 2020 03:37 AM UTC by Mike Kupfer
**Last Updated:** Sun Dec 31, 2023 01:34 AM UTC
**Owner:** Bill Wohler


The docstring for mh-funcall-if-exists says "Call FUNCTION with ARGS as parameters if it exists."
But it will only do that if FUNCTION was defined at compile time. If it wasn't, then the function will not ever be called, even if it's defined at runtime.


---

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] #494 mh-funcall-if-exists ignores function if it wasn't there at compile time

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

- **status**: open --> closed-fixed
- **assigned_to**: Bill Wohler



---

**[bugs:#494] mh-funcall-if-exists ignores function if it wasn't there at compile time**

**Status:** closed-fixed
**Milestone:** Unassigned
**Created:** Mon Jan 20, 2020 03:37 AM UTC by Mike Kupfer
**Last Updated:** Sun Dec 31, 2023 01:33 AM UTC
**Owner:** Bill Wohler


The docstring for mh-funcall-if-exists says "Call FUNCTION with ARGS as parameters if it exists."
But it will only do that if FUNCTION was defined at compile time. If it wasn't, then the function will not ever be called, even if it's defined at runtime.


---

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] #494 mh-funcall-if-exists ignores function if it wasn't there at compile time

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

This wasn't the only unused macro. The list of unused macros in mh-acros.el is: mh-do-in-gnu-emacs, mh-do-in-xemacs, mh-funcall-if-exists, defun-mh, defmacro-mh, mh-make-local-hook,mh-mark-active-p. These have been deleted on the master branch.


---

**[bugs:#494] mh-funcall-if-exists ignores function if it wasn't there at compile time**

**Status:** open
**Milestone:** Unassigned
**Created:** Mon Jan 20, 2020 03:37 AM UTC by Mike Kupfer
**Last Updated:** Thu Nov 02, 2023 03:43 PM UTC
**Owner:** nobody


The docstring for mh-funcall-if-exists says "Call FUNCTION with ARGS as parameters if it exists."
But it will only do that if FUNCTION was defined at compile time. If it wasn't, then the function will not ever be called, even if it's defined at runtime.


---

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] #504 mh-mm-inline-media-tests needs an autoload cookie

[Stephen G. <gi...@us...>]

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



---

**[bugs:#504] mh-mm-inline-media-tests needs an autoload cookie**

**Status:** closed-fixed
**Milestone:** Unassigned
**Created:** Thu Nov 02, 2023 04:03 PM UTC by Stephen Gildea
**Last Updated:** Fri Nov 03, 2023 07:58 PM UTC
**Owner:** Stephen Gildea


mh-mm-inline-media-tests needs an autoload cookie because it is referenced by mh-display-msg.

This bug has been present since mh-mm-inline-media-tests was introduced, in 2002, but was masked until recently because mh-display-msg also calls mh-make-buffer-data, which autoloads the needed mh-mime library.

In April 2023, commit feef1a0592d updated the byte compiler optimizer to know that make-hash-table is side-effect-free.  Because make-hash-table is the core of mh-make-buffer-data, mh-make-buffer-data is now inlined by the compiler, and calling it no longer loads mh-mime as a side effect.



---

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] #504 mh-mm-inline-media-tests needs an autoload cookie

[Stephen G. <gi...@us...>]

This was fixed July 2023 by Bill Wohler, who added "(require 'mh-mime)" to mh-show.el with commit a92ee5ca3c.


---

**[bugs:#504] mh-mm-inline-media-tests needs an autoload cookie**

**Status:** open
**Milestone:** Unassigned
**Created:** Thu Nov 02, 2023 04:03 PM UTC by Stephen Gildea
**Last Updated:** Thu Nov 02, 2023 04:03 PM UTC
**Owner:** Stephen Gildea


mh-mm-inline-media-tests needs an autoload cookie because it is referenced by mh-display-msg.

This bug has been present since mh-mm-inline-media-tests was introduced, in 2002, but was masked until recently because mh-display-msg also calls mh-make-buffer-data, which autoloads the needed mh-mime library.

In April 2023, commit feef1a0592d updated the byte compiler optimizer to know that make-hash-table is side-effect-free.  Because make-hash-table is the core of mh-make-buffer-data, mh-make-buffer-data is now inlined by the compiler, and calling it no longer loads mh-mime as a side effect.



---

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] #504 mh-mm-inline-media-tests needs an autoload cookie

[Stephen G. <gi...@us...>]

---

**[bugs:#504] mh-mm-inline-media-tests needs an autoload cookie**

**Status:** open
**Milestone:** Unassigned
**Created:** Thu Nov 02, 2023 04:03 PM UTC by Stephen Gildea
**Last Updated:** Thu Nov 02, 2023 04:03 PM UTC
**Owner:** Stephen Gildea


mh-mm-inline-media-tests needs an autoload cookie because it is referenced by mh-display-msg.

This bug has been present since mh-mm-inline-media-tests was introduced, in 2002, but was masked until recently because mh-display-msg also calls mh-make-buffer-data, which autoloads the needed mh-mime library.

In April 2023, commit feef1a0592d updated the byte compiler optimizer to know that make-hash-table is side-effect-free.  Because make-hash-table is the core of mh-make-buffer-data, mh-make-buffer-data is now inlined by the compiler, and calling it no longer loads mh-mime as a side effect.



---

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] #494 mh-funcall-if-exists ignores function if it wasn't there at compile time

[Stephen G. <gi...@us...>]

In fall 2021 (for Emacs 29), Stefan Kangas removed all calls to mh-funcall-if-exists and declared it obsolete.  Probably all that remains to be done is to remove the definition itself.


---

**[bugs:#494] mh-funcall-if-exists ignores function if it wasn't there at compile time**

**Status:** open
**Milestone:** Unassigned
**Created:** Mon Jan 20, 2020 03:37 AM UTC by Mike Kupfer
**Last Updated:** Sun Jun 28, 2020 01:12 AM UTC
**Owner:** nobody


The docstring for mh-funcall-if-exists says "Call FUNCTION with ARGS as parameters if it exists."
But it will only do that if FUNCTION was defined at compile time. If it wasn't, then the function will not ever be called, even if it's defined at runtime.


---

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: SourceForge deprecating RSA keys?

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

I forgot to mention, the telltale sign that the remote server is no
longer accepting your RSA key is this in the ssh -v output:

debug1: send_pubkey_test: no mutual signature algorithm

Bill Wohler via mh-e-devel <mh-...@li...> wrote:

> The web.sourceforge.net host key just changed. Having dismissed that
> warning, I then found that my RSA key no longer worked. Upon a little
> research, it appears that RSA is no longer a trusted algorithm. I
> thought longer keys were still OK. Anyway, ECDSA and ED25519 seem to be
> preferred.
> 
> I created a new key with "ssh-keygen -t ecdsa" and uploaded it to
> SourceForge. I was then able to perform my monthly backup of the MH-E
> SourceForge site.
> 
> Hope this info helps. If not at SourceForge, perhaps somewhere else.
> 
> -- 
> 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
> 

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

SourceForge deprecating RSA keys?

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

The web.sourceforge.net host key just changed. Having dismissed that
warning, I then found that my RSA key no longer worked. Upon a little
research, it appears that RSA is no longer a trusted algorithm. I
thought longer keys were still OK. Anyway, ECDSA and ED25519 seem to be
preferred.

I created a new key with "ssh-keygen -t ecdsa" and uploaded it to
SourceForge. I was then able to perform my monthly backup of the MH-E
SourceForge site.

Hope this info helps. If not at SourceForge, perhaps somewhere else.

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

Bikeshedding (was: mh-sub-folders-cache being cleared)

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

I just looked up bikeshedding too. I didn't see that coming :-).

In software, some folks might consider getting the name of a function
right "bikeshedding." However, if you get the name wrong, you doom you
and users of your API forever.

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

> Bill,
> 
> > Note that date, from, and body are not contractions.
> 
> i see.  yes.  and also "to", "cc" are < 4 characters.  still, i'd go for
> setting 4 character max.  for those trying to decode a folder name, i
> would like the consistency.
> 
> (i'd also be happy with the mairix "c:", etc.; for me, partly it's the
> readability, partly the consistency.)
> 
> but, not a big deal.  (now i looked up "bikeshedding". :)
> 
> cheers, Greg
> 
> 
> _______________________________________________
> 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: mh-sub-folders-cache being cleared

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

Bill,

> Note that date, from, and body are not contractions.

i see.  yes.  and also "to", "cc" are < 4 characters.  still, i'd go for
setting 4 character max.  for those trying to decode a folder name, i
would like the consistency.

(i'd also be happy with the mairix "c:", etc.; for me, partly it's the
readability, partly the consistency.)

but, not a big deal.  (now i looked up "bikeshedding". :)

cheers, Greg

Re: mh-sub-folders-cache being cleared

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

Note that date, from, and body are not contractions.

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

> Bill,
> 
> > Cool. Actually, from, date, and body are short enough (4 characters) and
> > can be included in full. I'd stick with s: and a: for subject and
> > anywhere, since "su" and "an" are kind of weird. Thus,
> > 
> > from:<from>_to:<to>_cc:<cc>_date:<date>_s:<subject>_body:<body>_a:<anywhere>
> > 
> > What do you think?
> 
> what about the first four characters, so subj: and anyw:?  there's some
> sort of consistency there maybe.
> 
> cheers, Greg
> 
> 
> _______________________________________________
> 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: mh-sub-folders-cache being cleared

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

Bill,

> Cool. Actually, from, date, and body are short enough (4 characters) and
> can be included in full. I'd stick with s: and a: for subject and
> anywhere, since "su" and "an" are kind of weird. Thus,
> 
> from:<from>_to:<to>_cc:<cc>_date:<date>_s:<subject>_body:<body>_a:<anywhere>
> 
> What do you think?

what about the first four characters, so subj: and anyw:?  there's some
sort of consistency there maybe.

cheers, Greg

Re: mh-sub-folders-cache being cleared

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

Cool. Actually, from, date, and body are short enough (4 characters) and
can be included in full. I'd stick with s: and a: for subject and
anywhere, since "su" and "an" are kind of weird. Thus,

from:<from>_to:<to>_cc:<cc>_date:<date>_s:<subject>_body:<body>_a:<anywhere>

What do you think?


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

> Bill Wohler wrote:
> 
> > I wouldn't want to use the full term. I often specify the date, from,
> > and subject and if the full terms are used, the name gets truncated
> > before we get to the good bits. If you've got a compromise, I'm all
> > ears.
> 
> What do you think about 2 letters per term?
> 
> fr:<from>_to:<to>_cc:<cc>_da:<date>_su:<subject>_bo:<body>_an:<anywhere>
> 
> mike
> 

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

Re: [patch] workaround for SF#499

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

I'd rename the do-show-addr variable to show-addr.

Can you also replace the comments that say "Work around SF#499 (clash
between goto-address and shr)" with a little more description about the
clash? What specifically is the problem/symptom and what's the
work-around? This isn't clear without reviewing SF#499. Add SF#499 in
parens at the end of the sentence.

Thanks!

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

> Mike Kupfer wrote:
> 
> > What do folks think of the attached patch?
> 
> Oops, I didn't test this enough; it still needs work.  In particular, it
> fails to invoke goto-address for simple-text emails.
> 
> 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: mh-sub-folders-cache being cleared

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

Bill Wohler wrote:

> from:<from>_to:<to>_cc:<cc>_date:<date>_s:<subject>_body:<body>_a:<anywhere>
> 
> What do you think?

Sure, let's go with that.

thanks,
mike

Re: [patch] workaround for SF#499

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

Mike Kupfer wrote:

> What do folks think of the attached patch?

Oops, I didn't test this enough; it still needs work.  In particular, it
fails to invoke goto-address for simple-text emails.

mike