🚀 go-pugleaf

blueman wrote:
> Uday S Reddy <uDOTsDOTreddy@cs.bham.ac.uk> writes:
>> Sorry, JJK.  I find this rather convoluted.  
> Personally, I think my way of doing it is "clever" ;) since:

Indeed, it is.  But "cleverness" is damaging to software by entangling 
one thing with another.  If you change one thing, then everything else 
breaks.  So, the cleverest software is in fact streamlined software.

I was assuming that the only reason for the 
vm-pipe-messages-to-command-[start|end] variables is to provide 
separators for the vm-pipe-messages-to-command function.  If this 
function is given the stored separator lines instead, then the 
variables don't have a purpose any more and I would want to eliminate 
them.

>> I have already added yesterday a variable called
>> `vm-message-include-separators' to alter the meaning of what a
>> "message" means.  All that is needed now is to call
>> vm-pipe-message-to-command after setting this variable to t.

This wasn't enough, unfortunately.  There is an additional parameter 
`nowait' for the plural version of the function, which seems to 
require a more complicated protocol with the process.  So, I couldn't 
simply piggy back on the singular version of the function.  When I 
modified the plural version of the function to get rid of the extra 
separator lines, it hung on the examples I tried.  So, I will have to 
come back to this later.  Meanwhile, you seem to have something that 
works.  So, please go ahead and use it, and I will make sure that you 
will have a working version of the function when you have to upgrade.

>> This will be in 8.1.1-devo version in a few minutes.

Famous last words!

> Thanks. Have you also included my bug fixes to:
>      vm-pipe-command-exit-handler
>      vm-pipe-messages-to-command

I can't find them.  Did you post them to the newsgroups or Launchpad? 
   Actually, Launchpad is much better for posting bug reports because 
we can keep track of things better.  But newsgroups are better for 
discussion of course.

Cheers,
Uday