🚀 go-pugleaf

Julian Bradfield <jcb@inf.ed.ac.uk> writes:

> On 2010-01-04, blueman <NOSPAM@nospam.com> wrote:
>
> Then you didn't ask for what you wanted. Beside which, spamassassin is
> perfectably capable of taking an *individual* message in standard
> form and processing it - indeed, that's what it does by default, isn't
> it? If you want to feed it a folder in mbox format, don't you have to
> give a special argument?

I'm talking about the sa-learn Bayesian learning portion of
spamassassin. Feeding it one message at a time is exceedingly slow since
you have to restart sa-learn each time.

> The message together with the folder data is not a legal
> message. That's very destructive - I lost quite a bit of mail a few
> years ago because I didn't notice that various filters were barfing on
> the From line that procmail added.

And you can even more easily lose a sequence of messages by deleting the
separators between them. Just because you didn't notice the filters
doesn't mean that others won't have other problems...

> If you absolutely NEED to contenate a bunch of messages and pipe the
> resulting folder to a command, then do it.

Well, that was the whole reason that Robert *added* the command
vm-pipe-messages-to-command (where the 's' is plural) ... You keep
talking about this command as if it is yet to exist...
>
>> Do you have any specific use cases where the change I am proposing will
>> mess up existing code or applications? Theoretical problems encountered
>
> Yes: it will break every use I make of the | command in VM, where I'm
> always piping to a progam that expects (or I want, in the case of
> printing) to receive a message in RFC2822 form.

> In any case, I don't understand your use case:
> vm-pipe-message-to-command says that it runs the command separately
> for each message - how are you using it?

I am talking about (and using) the vm-pipe-messages-to-command...

And I would guess that if you used that command it would break at least
as many programs since external programs *need* to see a separator
because otherwise they have *no* way of separating messages. Indeed,
that is the whole purpose of message separators.

I can guarantee that when passing multiple concatenated messages (which is what
vm-pipe-messages-to-command does), it is much easier and more likely for
an external program to work with the separators than without the
separators. Indeed a concatenated sequence of alternating headers and
messages bodies is pretty meaningless if you can't tell where one
begins and the other ends. I would have thought that would be pretty
obvious...

It really seems that you are talking about a separate command and use
case. When using vm-pipe-message-to-command which seems to be your use
case, it makes sense to most of the time leave out the separators since
they are not needed when looking at a single message.

For my use case of using vm-pipe-messages-to-command, you need the
separators unless you want to treat it all like one big run-on chunk of
text. In which case why even have a notion of body or text at all or why
not just caesar-rotate it all ;)

Perhaps a compromise solution that would work for both cases would be to
add a flag to both routines that would toggle whether or not separators
are included -- technically, whether headers start at (vm-headers-of m)
vs. (vm-start-of m) and whether the body ends at (vm-text-end-of m)
vs. (vm-end-of m).

And based on your input, I would suggest that for
vm-pipe-message-to-command, this flag default to no separators and for
vm-pipe-messages-to-command it default to including separators. And
since it seems like you are not aware of let alone using
vm-pipe-messages-to-command and since the command has always been pretty
broken and is unlikely to have been used by many people if at all, this
change shouldn't create problems for you or others ;)

And I would be happy to write the trivial code change to make this all
work...