🚀 go-pugleaf

Uday S Reddy <uDOTsDOTreddy@cs.bham.ac.uk> writes:

> blueman wrote:
>
>> Since the usual reason for splitting/piping messages to an external
>> shell command is to pass the message to some standard 3rd program, it
>> would be helpful to use standard conventions -- by which I mean
>> something relatively consistent with 'formail' or better yet the RFC's.
>> In particular, when you ask for the "entire message", I at least expect
>> the entire message.
>
> Boy, you guys are really busy today, aren't you?
>
> Unfortunately, it looks like 'formail' has let you down.  Julian is
> right.  RFC 2822, which specifies the format of internet messages,
> only allows headers and body in the messages.  The leading "From "
> line and the trailing empty line are *separators* used in the "mbox
> database" format, as specified in RFC 4155.  These are not part of the
> messages themselves.
>
> Your change will break all users that are trying to interface to
> standards-compliant tools.
>
> You can have either a 4-prefix-argument version or customization
> variables to include the separators in the "message".  Which would you
> prefer?
>
Please see my other post. To me it seems like the difference is that
Julian is using vm-pipe-message-to-command where separators are not
needed and in his case at least has caused him confusion and data loss.

I am mostly interested in vm-pipe-messages-to-command where separators
(whether mbox or otherwise) are pretty essential if you want to preserve
any sense of where a message starts or ends.

My proposed compromise is to add an optional flag to the respective
routines that toggles the inclusion/exclusion of separators with the
default be to exclude separators in the single message case and include
them in the multiple message case... This "compromise" should result in
maximizing the possibility that piping to third party programs will work
with both commands.