🚀 go-pugleaf

blueman wrote:
> Let's start on a clean slate here and hopefully let's avoid any flame
> wars or recriminations. I think we are both just trying to improve this
> great program.

That is starting on a kind note, but I don't see much different in 
what you are saying.  You are not asking for a bug fix.  You are 
simply asking me to change the program to suit your taste.  If the 
taste is so important to you, then there is only one way to achieve 
it.  You have to join the VM development team and take 
*responsibility* for maintaining the code.  Then you are welcome to 
change it according to your taste.  Even then, we might debate issues 
but your taste will come with a burden of responsibility which will 
give it weight.  What you are doing now is basically back seat driving.

> Here is a patch against your latest *668* revision that cleans things up a
> bit more. In particular,
> 
>     - It removes the confusing/redundant use of the 2nd argument command
>       (since it is available via process-command). 

It is not redundant.  process-command returns a list of strings, and 
the exit handler wants a string. The types don't match.  You haven't 
yet said whether you are proposing a patch that has been tested!

>     - Also, it removes the duplicate and potentially interfering
>       functionality created by the unnecessary variable
>       vm-message-includes-separators. Instead, this functionality can be
>       accessed using 4 prefix arguments which is 100% consistent usage
>       with the other flavors of addressing message parts in
>       vm-pipe-message-part and vm-pipes-message-to-command.

So, to run a command on a bunch of marked messages with separators 
included, one must type

   M n C-u C-u C-u C-u | |

and, if one makes a mistake anywhere, one must go back and type the 
whole thing all over again!  I don't see that as a good design.  And, 
what if I am always interested in applications that want separators. 
Am I for ever doomed to the fate of typing C-u's?

In any case, this doesn't affect you.  You are interested in the 
plural version of the operation, and this affects the singular version 
of the operation.  So, why don't you let go?

>       Note, I also added code in vm-pipe-messages-to-command that allows
>       the 4 prefixes to override the separate start/end separators
>       rather than conflicting with them (as is the case in your code)

That is a good point.  I will change the plural version of the 
operation to ignore the vm-message-includes-separators variable.

> If I should be submitting patches instead to launchpad please tell me
> where and how to do that.

The way you have formulated the patch this time is perfectly fine and 
usable.

> Well, the plural version is *much* faster than the
> vm-pipe-message-to-command multiple times.
> 
> Also how else would you enable an external command to act on multiple
> messages?

You can run 'cat | whatever' with vm-pipe-message-to-command.

> The whole 'culture' of vm is to allow functions to act on marked
> messages as well as individual ones wherever it makes sense.

Except that marked messages only work with keyboard commands, not M-x 
commands.  This a serious flaw in the design of VM.  Marked messages 
are a very powerful tool, but I don't use them much because they are a 
pain to use.  If I have time, I might implement some kind of a 
selection mechanism that is easier to use.

> Also, vm-pipe-messages-to-command is *much* more powerful in that it
> allows asynchronous calling of commands. Do you always want to wait for
> a command to complete before using emacs again?

I have told you multiple times that vm-pipe-messages-to-command is not 
working on Windows Cygwin.  It hangs, and the whole Emacs freezes. 
Unless this is caused by some bug in Windows or Cygwin, this would be 
quite unacceptable.  I will test it on Linux when I get a chance.

>> My reasoning would be as follows.  The official definition of a
>> > "message" includes headers and body, but not the separators.  But,
>> > apparently, some external applications want the separators as well. To
>> > allow the users to use those applications, I would provide a variable
>> > that includes separators along with the messages.  The users that need
>> > to use those applications would set that variable, either in their .vm
>> > file or in their own user-defined functions, and the job is done.  End
>> > of story.
> 
> You said you like clean code -- well one of vm's biggest problems in my
> opionion is that it has way too many variables and settings. We need to
> get away from the habit of just adding more... Plus in the context of a
> single message, adding the separators is just really another view like
> the one for piping visible headers vs. all the headers (and we don't
> have a variable to toggle between piping all vs. visible headers)
> 
> Clean code means consistent usage...

This is not what I asked for.  You labeled my solution as a "kludge" 
which means that it is clumsy and inelegant.  I have given you what is 
in my opinion a clean explanation for it.  You haven't pointed out 
what is clumsy or inelegant about it.

Minimizing the number of variable settings is a separate issue.  In 
this particular case, I think the variable is a reasonable one because 
it describes what is meant by a "message" in the user's environment. 
Further, I don't want to force the user to type 4 prefix arguments in 
the middle of a compulsory keyboard command.  Usability takes priority 
over all other considerations.

In the interest of minimizing the number of variable, why don't you 
give up the clumsily named vm-pipe-messages-to-command-start/end 
variables and use the new variable in their place?  I have tried to 
talk you into it a few days ago and you refused.

> And I agree that there are too many redundant commands here.
> 
> I would *seriously* considering replacing vm-pipe-message-to-command
> with the much more powerful, extensible and compatible
> vm-pipe-messages-to-command. Such a replacement would be transparent to
> users of the original vm-pipe-message-to-command code.
> 
> The ability to act on multiple messages and to pipe asynchronously is *awesome*

I don't mind replacing the old operations by the new ones if you can 
convince me that the new ones actually work.  Give me a version of the 
operations that will work on Windows Cygwin running cat.  That would 
be a good start.

> Also, I have already said that in the future I am happy to use launchpad but I
> was not aware of it when this thread started.

Please do.  That will work a lot better.

Cheers,
Uday