🚀 go-pugleaf

blueman <NOSPAM@nospam.com> writes:

> Before, even with multiple emacsclients, vm knew to always keep the summary
> buffer and the presentation buffer in the same client.
>
> Now 8.1.0 seems to do the opposite. It preferentially uses the entire
> screen for the summary buffer and leaves the presentation buffer open on
> another emacsclient instance (and vica-versa). To get them back on a
> single screen, I need to manually split the screen and then manually
> switch buffers.
>
> Perhaps there is some new vm variable that causes this behavior but if
> so the default behavior should not be changed without documentation.
>
> This is *extremely* annoying.

Actually even worse, if I call 'vm' and the 'vm' buffer is open in
another (hidden) emacsclient terminal, the the 'vm' buffer doesn't open
up in my current terminal. Presumably someone has removed a line that
pops to the vm-buffer....

blueman <NOSPAM@nospam.com> writes:
> blueman <NOSPAM@nospam.com> writes:
>
>> Before, even with multiple emacsclients, vm knew to always keep the summary
>> buffer and the presentation buffer in the same client.
>>
>> Now 8.1.0 seems to do the opposite. It preferentially uses the entire
>> screen for the summary buffer and leaves the presentation buffer open on
>> another emacsclient instance (and vica-versa). To get them back on a
>> single screen, I need to manually split the screen and then manually
>> switch buffers.
>>
>> Perhaps there is some new vm variable that causes this behavior but if
>> so the default behavior should not be changed without documentation.
>>
>> This is *extremely* annoying.
>
> Actually even worse, if I call 'vm' and the 'vm' buffer is open in
> another (hidden) emacsclient terminal, the the 'vm' buffer doesn't open
> up in my current terminal. Presumably someone has removed a line that
> pops to the vm-buffer....

OK - I figured out the problem.
I need to set vm-search-other-frames to nil

Not sure what changed in my config because I hadn't noticed this problem
before -- but good to know there is a variable that solves this...

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.

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.

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

Cheers,
Uday

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