🚀 go-pugleaf

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

> blueman wrote:
> 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!

My patch has been tested and works on multiple different types of
commands. If you have an example that doesn't work, please post it so I
can replicate it...

>
>>     - 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?

Why is 3 C-u good for showing virtual headers?
And adding a 4th C-u is not very hard since your fingers are presumably
already on the key.

Plus using the separator is really as Julian suggested (and you
confirmed) a deviant case since when piping single messages, the
separator really has no use or meaning. To quote Julian:

      The initial From line is NOT part of the RFC standard, nor is it
      part of the message. It's an obsolete Unix mbox hack that should
      have been killed off decades ago - the mbox format is patently
      unsuitable, leading to abominations like From-stuffing.  I've had
      immense trouble with very broken mail systems (procmail) that
      insist on putting the From in where it has no business - it caused
      standards-compliant mail filters to break, because they saw a From
      instead of a proper message.

Even I (who is the one who requested the From_ header) don't have a use
case for it in the case of individual messages. I only need it when
piping multiple messages.

And if you truly need a separator on a single message, then use
vm-pipe-messages to command on a single message with the
vm-pipe-messages-to-command-start/end variables set to their default
't'. Or if you insist on non-standard message definition then just use 4
C-u's if you prefer.

>
> 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?

But it *does* effect the plural version since the plural version calls
the same routine. So if you set your variable for use in the single
message routine, then it will *mess* up the multi-message routine.  So
you will need to continually toggle on-and-off this variable. This is
ridiculous and will inevitably lead to errors.

Thus your "fix" for the single message case, *breaks* the multi-message
case!!!!


I don't know how many times I have to say this!!!!!


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

I already did that in a clean way in my patch. Please look at it.

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

I don't understand. You are just catting a single message.

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

True - but vm-pipe-message-to-command is bound to a keyboard
command. And marked messages are *very powerful* even if you don't use
them. I don't find them to be a pain at all but if you do, then don't
use them, but I can assure you that many users at least historically
have found marks extremely useful if not indispensible.

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

I just tested it on Windows Cygwin and it works just fine. So perhaps
there is something wrong with your setup. 

How about providing more info than "doesn't work"? You are always
asking others to submit detailed reports, perhaps you could do the
same. It would be much easier than me trying to convince you that it works.

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

1. It adds an unnecessary variable
2. It is inconsistent with the rest of usage of vm-pipe-message-part
3. As per Julian, including the separator when using a single message is
   a deviant case. At least as deviant as defining visible headers as a
   type of headers. Since visible headers uses a C-u relative to headers,
   why shouldn't your special case also use a C-u. Why should we be
   adding a variable to support a rare (and wrong) special case when the
   functionality is available and more appropriate to
   vm-pipe-messages-to-command where having separators makes sense.
4. It requires another change to vm-pipe-messages-to-command to prevent
   your change from breaking that command
>
> 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.

So do the same for visible headers instead of C-u C-u C-u since a
variable would then describe the meaning of headers.
My point is that adding an arbitrary variable for one modification and
not for another exactly analogous one is precisely the definition of a
kludge.
>
>
>> 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.
>

Just so you know, I twice completely reworked my code in response first
to Julian's objection that my definition of message is non-standard and
second in response to your objection that my code was "too clever". Yet
you have claimed that I am too fixated on code. However, you seem to be
the one who is unwilling to change your approach despite what I believe
to be reasonable objections, alternatives, and new code!!!