🚀 go-pugleaf

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

> blueman wrote:
>>
>> OK - I found your revisions.
>
> Actually, you didn't.  These were the old revisions that I had made
> before you even told us that you were interested in the
> vm-pipe-messages-to-command (the plural version of the operation).
>
> I uploaded the current revision this morning.  I had intended to wait
> for your feedback before I uploaded the changes.  But...
>
>> The way you implemented it is really just a kludge which adds an
>> additional unnecessary variable vm-message-include-separators. 
>
> You seem to love to argue about code.  I don't.  The code I like is
> simple, direct and clean.  It has a manual that is short, clear and
> understandable.  It has as few features as possible to serve the
> function it is designed to do, but these features would be as powerful
> as possible without being complex.  Unfortunately, VM is already well
> past all of these things.  I am only trying not to make it any worse
> than it is.

Pot meet kettle. Let's stop making this personal.

I don't like to argue about code, but your code has several shortcomings
that go against being "short, clear, and understandable". And I don't
want any more kludgey and buggy code added to vm. In particular, your
code: 
     - Adds an unnecessary new variable and vm already has way too
       many variables.
     - Breaks the consistency of how special cases are treated -- the
       other special cases of body only, header only, visible headers only
       are treated with prefix args but you add a special case that is
       treated with a new variable for no apparant reason.
     - Results in redundant separator insertion when using
       vm-pipe-messages-to-command since if your varialbe is set and
       Robert's variables are set then the separators get inserted
       twice. This potential (and unnecessary) conflict is not even
       documented in your code.

> If I had my own way, I would never had added the plural version of the
> command (which has 3 versions) or its associated variables (2 of
> them).  I would have made the changes that you find in revision 664,
> which includes just this one variable vm-message-includes-separators
> and its effect on vm-pipe-message-to-command.
>

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?

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

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?

If anything, the vm-pipe-message-to-command should be eliminated or
replaced with the current version of vm-pipe-messages-to-command since
vm-pipe-messages-to-command is a true superset of the original function.

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

>
> If you still want to maintain that this is a "kludge", explain your
> reasoning.

Explained as above.... And again, I am not trying to attack you or the
code. I truly believe as explained above that your code is messy and
will lead to confusion and wrong results (e.g., duplicate separators).\
>
> ----
>
> But I am not proposing to delete your favourite functions and
> variables.  They were already there when I started and they will
> continue to be there.  I am only trying not to make it any worse than
> it is.  I don't have a plan to clean up VM.  It is too big a program
> for that.

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

The other vesions are relatively consistent with standard emacs process
usage where one is given the option to send the output to a string
rather than a buffer
>
> ----
>
> One final remark.  You have mentioned that I was engaging in some kind
> of a public rebuke.  But it seems to me that you are one that is
> repeatedly choosing public fora to make your points.  People that are
> focused on solving problems are quite happy to report them on
> launchpad or send us a bug report, get the problems fixed and go on
> with their lives.  What is it that you are trying to do?
>
Please stop the ad-hominem. You know well that I am trying to get the
code fixed properly and that I have incorporated all of your inputs and
Julian's in the code -- going so far as to rewrite it multiple times to
accommodate your valid inputs. This thread would be a lot shorter if you
stopped trying to argue with me rather than looking at the code I keep
providing. If you look back on this thread, you will see that you have
provided perhaps one piece of code (which was buggy) while almost all of
my posts have been code-related.

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.

> Cheers,
> Uday
Cheers and *please* stop trying to argue with me and let's focus on
getting the code right!!!