🚀 go-pugleaf

Uday S Reddy <uDOTsDOTreddy@cs.bham.ac.uk> writes:
> blueman wrote:
>
>> OK - I figured out the problem.
>> I need to set vm-search-other-frames to nil
>
> Maybe.  Or, maybe not.  There is nothing in the documentation of
> vm-search-other-frames which says that it should cause this
> behaviour. Further, the default setting of the variable should work
> reasonably. So, there is still a problem somewhere.
>
Indeed I only figured that out by looking at the code...
Isn't elisp code documentation enough? ;)

Actually, the function isn't documented but the variable explains the
behavior though it may take a couple of reads (which still only
helps if you read through the code to find the variable...)

While it is not my *preferred* default behavior, I can understand why it
is for others. If you keep multiple frames open you may want 'vm' to
alway go to a dedicated vm frame.

This doesn't work for me since I often leave emacsclient open in
multiple different ssh logins. So if vm is open in an ssh session from a
machine that I may not even be on, then the vm focus keeps getting sent
to that other ssh session. And the only thing I can do is to either
manually switch to the vm buffers (separately for both summary &
presentation) or to kill the emacsclients in the other sessions and run
vm again.

So, I don't think it is broken... more a question of what the right
default behavior and value for the variable is...

In fact, vm.el, explicitly provides functions that internally set
vm-search-other-frames to nil. But this doesn't help when you are used
to just typing 'vm' to refresh your mail and go to the vm screen...

> VM's startup routine is slightly damaged.  There were some
> entanglements that were introduced in 8.0.x or 8.1.x, which weren't
> there in Kyle's versions.  They have been causing all kinds of bad
> behaviour.  The following recent bug report is an example:
>
>   https://bugs.launchpad.net/vm/+bug/502371
>
> To fix these problems, I have been changing the startup sequence which
> worked fine in 7.19, but doesn't work correctly now.  In fact, I had
> been making such changes ever since I started using 8.1-devo and Rob
> was still in charge.  This is not ideal.  We need to find those
> entanglements that broke the original startup sequence and correct
> them.  But it will likely take a long time.

Sounds good... but some of that functionality was added for good reason
so I hope you are not deleting the added functionality but only
eliminating bugs or cleaning up code...

(In fact, I know that I contributed the recursive vm call functionality
since otherwise the vm init file gets read in before some vm variables
are ready to be set which means that get set before being defined...)


> So, I encourage you to get to the bottom of this problem.  I still
> haven't received anything from you via the vm@lists.launchpad.net
> address.  I need to try things out with your settings to see where the
> problems might be.  It occurs to me that if you are spoofing your
> From' address, launchpad might be rejecting your mail, thinking it is
> spam.  Or, you can send it to my personal address, which is always
> advertised.  (You need to replace 'DOT' with '.')
>

That could be since I do spoof my From...

But do you really still need the bug report since I sent you the two
trivial patches (one adds a ',' and the other adds the input variable
'command')?