[bug-mailutils] mh strange behaviour

[Sergey Poznyakoff]

Hi Pierre-Jean,

1) When composing a message, 'whatnow' could (should?) offer the
possibility to call 'mhn' before sending the message. The book "Mh &
NMH..." indicates that depending of the implementation, whatnow
http://rand-mh.sourceforge.net/book/mh/wormes.html#mhEdanau

Nice point. I'll implement it.

2) I have a problem with the PAGER and moreproc variables.
As far as I understand, when the showproc is the default one ('mhn'),
and the message is not a mime one, all options given to the PAGER
environment variable are not understood as options, but as a file to
display.

I have pushed the commits d69ca8dc and d2952d1c which fix this
problem as well as the cur issue. They also enable "show" to
do the right thing when it is named "next" or "prev". Please
pull them. If you have trouble building MU from git, let me
know and I will provide a tarball for you.

Regards,
Sergey

[Fichet]

Hello Sergey,

Thank you for your answer and all the work done on mailutils. It's a
great piece of software, which is, as far as I can judge, quite well
thought.

I have discovered two others little things on mu-mh.

1) When composing a message, 'whatnow' could (should?) offer the
possibility to call 'mhn' before sending the message. The book "Mh &
NMH..." indicates that depending of the implementation, whatnow
understands the commands 'edit mhn' or 'mime'. Cf:
http://rand-mh.sourceforge.net/book/mh/wormes.html#mhEdanau

2) I have a problem with the PAGER and moreproc variables.
As far as I understand, when the showproc is the default one ('mhn'),
and the message is not a mime one, all options given to the PAGER
environment variable are not understood as options, but as a file to
display.

Example:

$ export PAGER='less -Rs'
$ show 1
show: unable to exec less -Rs: No such file or directory
# 'less -Rs' works usually well.
$ echo "moreproc: less" >> .mh_profile
$ show 1
show: unable to exec less -Rs: No such file or directory
# apparently 'moreproc' is not taken into account here.
$ export PAGER='less'
$ show 1
# this one works as expected.
$ export PAGER='less -Rs'
$ sed -i /moreproc/d .mh_profile
# the above deletes the moreproc line in .mh_profile
$ echo "showproc: mhl" >> .mh_profile
$ show 1
# this one works as expected too.

Here is my .mh_profile for the above problem:

Path: /home/me/Mail
Editor: /usr/bin/vim
Local-Mailbox: 'me <***@domain.org>'
inc: -changecur -truncate -file imaps://me%40domain.org:***@isp.example.com
mh-sequences: .mh_sequences
Unseen-Sequence: unseen
Previous-Sequence: pseq
Sequence-Neagation: not
pick: -list -sequence pick
repl: -format

Yes, indeed. The default -truncate and -changecur options are in effect
only unless at least one -file option is supplied. Once a -file option
is given, the safer -notruncate -nochangecur options are assumed.

That makes sense, indeed.

It would be desirable indeed, and in fact, the work is underway on
implementing the corresponding checks (UIDL for POP3 and uidvalidity
for IMAP4), for both movemail and inc.

3) 'show' does not update the 'cur' sequence when used. If 'cur' is s

Thanks for pointing that out. It's definitely a bug and I will fix it.

That is a nice thing to read, thank you so much for all that work !

Kind regards,
Pierre-Jean.

[Pierre-Jean]

Hello Sergey,

Post by Sergey Poznyakoff
I have pushed the commits d69ca8dc and d2952d1c which fix this
problem as well as the cur issue. They also enable "show" to
do the right thing when it is named "next" or "prev". Please
pull them.

After installation of the development version, I can confirm that
both issues are fixed. Thank you!

I wrote a manual page for mu-mh, which is maybe of interest for
mailutils. It does not cover all the details, but should help people
to get started. At least, all entries of the configuration files
should be mentionned.

Acutally, the man page comes with a TODO list, unfortunately:
- strings '@BINDIR@' and '@PREFIX@' need to be substituted at compile
time,
- a better english speaker than me should review it,
- the content has to be reviewed carefully by someone who knows well
mu-mh.

I can adapt its content to fit people's ideas and wishes, though. And
with the time needed for me to learn texinfo, I can, if needed,
translate it to that format.

Kind regards,
Pierre-Jean

[Pierre-Jean]

Post by Pierre-Jean
I wrote a manual page for mu-mh

To view the man page, one can use: man -l mu-mh.man

Regards,
Pierre-Jean.

[Pierre-Jean]

Hello alls,

As I am reading the "MH & NMH..." book, I am discovering some more
strange behaviour in mu-mh, which I still don't know if they are bugs,
not implemented features, or if they are a consequence of my own
configuration. I also have a question (point 4), and an idea (point
5).

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.

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".

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.

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?

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.

Kind regards,
Pierre-Jean.

[Sergey Poznyakoff]

Hi Pierre-Jean,

Thanks a lot for your report.

Post by Pierre-Jean
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.

Post by Pierre-Jean
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.

Post by Pierre-Jean
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
$ 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.

Post by Pierre-Jean
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.

Post by Pierre-Jean
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

[Pierre-Jean]

Hello Sergey,

It is a pleasure to send bug reports to such an enthusiastic
developper. So, I tested the lasts commits, and encountered a bug
introduced in whatnow with the new commit 383272e0 (I'm so sorry...)
The details are below.

Sergey Poznyakoff writes:

1) Draft-Folder

Post by Sergey Poznyakoff
You've discovered a serious bug that was introduced recently. I fixed
that.

Well, that's not exactly true, but thank you.

2) Local-Mailbox

Post by Sergey Poznyakoff
You are right, Local-Mailbox was not implemented. Please pull 82c5c521.

It works well now, and it's consistent with the signature entry.
For information, here's an extract of NMH's mh_profile man page:

Local-Mailbox : Your Username <***@some.host>
Tells the various MH tools what your local mailbox is. If
set, will be used by (as?) the default component files by
tools like comp and repl to construct your default From
header. The text used here will be copied exactly to your
From: header, so it should already be RFC 822 compliant. If
this is set, the Signature profile entry is NOT used, so it
should include a signature as well. (profile, default:
***@local.hostname)


3) whatnow "edit [program [parameters]]"

Post by Sergey Poznyakoff
Fixed in commit 383272e0. Please pull.

While calling an external program works well, a simple 'edit' now
fails, if the 'Editor' entry of mh_profile contains options (ie, vim
-c 'set ft=mail'). It was working well before, and it is still working
well if the 'Editor' entry has no options (ie, a simple 'vim').

4) show, mhl, mhn.

Post by Sergey Poznyakoff
I'll address this soon.

That's nice.

Post by Sergey Poznyakoff

Post by Pierre-Jean
5) In NMH, 'send' accepts the option '-mts smtp://example.com'.

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.

Localname, localdomain, and username are also given by the 'from'
parameter of the smtp url that mailutils understands, aren't they?
I'm also wondering if Local-Mailbox should'nt have this purpose too.


Kind Regards,
Pierre-Jean.

[Sergey Poznyakoff]

Hi Pierre-Jean,
Thanks for reminder. The 'Your Username' part is not supported yet,
but I'm going to implement that too.

Post by Pierre-Jean
While calling an external program works well, a simple 'edit' now
fails, if the 'Editor' entry of mh_profile contains options (ie, vim
-c 'set ft=mail'). It was working well before, and it is still working
well if the 'Editor' entry has no options (ie, a simple 'vim').

FWIW, that conforms with the behaviour of nmh whatnow utility. However,
I agree that it can be a useful feature, so I pushed the fix. Please pull.
Notice also that, albeit convenient, this functionality introduces a
certain ambiguity to the semantics of *-next entries in the profile.
Consider the following example:

editor: vi -i
vi-next: vi

The first "edit" command will invoke "vi -i", and all the subsequent
ones will invoke vi without additional options. That's OK. But what
if I want to provide a -next entry for the invocation of vi without
arguments? There's no way of doing that, because the * in *-next is
replaced by the command name only. I could implement (as extension)
somthing like "vi--i-next" to handle this case, but I haven't made my
mind yet. Opinions?

Post by Pierre-Jean
Localname, localdomain, and username are also given by the 'from'
parameter of the smtp url that mailutils understands, aren't they?

Yes, you're right.

Regards,
Sergey

[Pierre-Jean]

Hello Sergey,

Post by Sergey Poznyakoff
FWIW, that conforms with the behaviour of nmh whatnow utility. However,
I agree that it can be a useful feature, so I pushed the fix. Please pull.
Notice also that, albeit convenient, this functionality introduces a
certain ambiguity to the semantics of *-next entries in the profile.

Instead of putting my editor's options in mh_profile, I tried to use a
shell alias containing the said options, and whatnow was still unable
to launch the editor. Even if that's not the historical behaviour,
accepting options seems to reflect the usual shell ergonomy.

Post by Sergey Poznyakoff
The first "edit" command will invoke "vi -i", and all the subsequent
ones will invoke vi without additional options. That's OK. But what
if I want to provide a -next entry for the invocation of vi without
arguments? There's no way of doing that, because the * in *-next is
replaced by the command name only. I could implement (as extension)
somthing like "vi--i-next" to handle this case, but I haven't made my
mind yet. Opinions?

Concerning the *-next semantic, the default behaviour to consider the
command name *only* is my favourite one. The "vi--i-next" kind of
semantic seems error prone, and I believe very few people will want to
use the *-next capability to call the same editor with different
options. If that is really needed by some users, they probably could
use some shell aliases instead.

All that being said, I don't think my opinion has much value about MH:
For the short story, I was looking for a maintained "mail" command,
discovered mailutils, and found here an occasion to give mh a try.

Kind regards,
Pierre-Jean.