bug-mailutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-mailutils] mh strange behaviour


From: Sergey Poznyakoff
Subject: Re: [bug-mailutils] mh strange behaviour
Date: Wed, 31 May 2017 16:13:09 +0300

Hi Pierre-Jean,

Thanks a lot for your report.  

> 1) The "Draft-Folder" profile entry is readen, but seems to
> be ignored by "comp", "repl", and others, which does not put
> new drafts in that folder, but use Mail/draft instead.

You've discovered a serious bug that was introduced recently.  I fixed
that.  Please pull 744c4a9c.

> 2) Unless the profile entry "Alternate-Mailboxes" is filled with the
> default mailbox, "scan" does not recognizes mails sent by the user.
> I believe that comes from the fact the entry "Local-Mailbox" is not
> implemented by mu-mh, but I'm wondering if that's the expected
> behaviour, and if so, if the expected fix is to fill
> "Alternate-Mailboxes".

You are right, Local-Mailbox was not implemented.  Please pull 82c5c521.

> 3) I proposed in a previous message that whatnow could offer the
> possibility to call "mhn" to format mime messages in the form of the
> command "edit mhn" (as in rand-mh) or "mime" (as in nmh). I am
> discovering now that in rand-mh, "edit [program [parameters]]" calls
> an external program, whichever it is -- for example:
>     $ edit grep string
>     $ edit spell
>     $ edit vim -c 'set filetype=mail'
>     $ edit mhn
> Apparently, the mu-mh implementation of "whatnow edit" only allows to
> add options to the default editor, but not to call another program.

Fixed in commit 383272e0.  Please pull.

> 4) Is there a way to configure 'show' so that it uses 'mhl' to display
> non-mime messages, and 'mhn' to display mime messages? Or is it
> possible to tell 'mhn' to call 'mhl' when the message is not a mime
> one instead of simply paging it?

I'll address this soon.

> 5) In NMH, 'send' accepts the option '-mts smtp://example.com'. I
> believe that could make sense to have that option in mu-mh, since that
> would allow one to have all its configuration in the single mh_profile
> file, instead of relying on mtstailor too.

Yes, that's reasonable.  I'm going to implement that too.  However, it
will not eliminate the need for mtstailor, because, apart from the
url setting, the latter can also contain localname, localdomain and
username settings.

Regards,
Sergey



reply via email to

[Prev in Thread] Current Thread [Next in Thread]