exiting summary buffer does not move cursor in group buffer any more

exiting summary buffer does not move cursor in group buffer any more

[Jani Grönberg]

I recently updated my cvs gnus into a newer version
(gnus-CURRENT-20050123). Before when I exit a group with "q" or "c",
the cursor in group buffer was automatically changed to next group
containing unread messages. Now it stays in (the currently empty)
group. 

Is this a bug, and if not, can I get back the old behaviour? I seem to
have hard-coded in my brain the combination "c <space>", but it does
the wrong thing (for me) now.

//jani

-- 
A

Re: exiting summary buffer does not move cursor in group buffer any more

[Romain Francoise]

chardhros@spamtrap.oneccuva.org (Jani Grönberg) writes:

> Before when I exit a group with "q" or "c", the cursor in group buffer
> was automatically changed to next group containing unread messages.

Works here, and I don't see any recent change that could cause this...

> I seem to have hard-coded in my brain the combination "c <space>", but
> it does the wrong thing (for me) now.

Well, use `Z n' then.  ;-)

-- 
Romain Francoise <romain@orebokech.com> | No one should fear what they
it's a miracle -- http://orebokech.com/ | cannot see. --Beth Gibbons

Re: exiting summary buffer does not move cursor in group buffer any more

[Jani Grönberg]

Romain Francoise <romain@orebokech.com> writes:

> chardhros@spamtrap.oneccuva.org (Jani Grönberg) writes:
>
>> Before when I exit a group with "q" or "c", the cursor in group buffer
>> was automatically changed to next group containing unread messages.
>
> Works here, and I don't see any recent change that could cause this...
>
I don't have any intermediate versions at hand, but
gnus-CURRENT-20041125 does not exhibit this behaviour. Also exiting
group with "Q" sets the cursor normally. Probably I have some
customisation that causes the unwanted side effect, but the only thing
I could recognise is 
(add-hook 'gnus-exit-group-hook 'gnus-dribble-save) 
but removing this does not seem to change anything.

>> I seem to have hard-coded in my brain the combination "c <space>", but
>> it does the wrong thing (for me) now.
>
> Well, use `Z n' then.  ;-)
>
ok, but I still like the old way. I'll probably do more
experimentation with different startup files when I have time.

//jani

-- 
A

Re: exiting summary buffer does not move cursor in group buffer any more

[Jani Grönberg]

chardhros@spamtrap.oneccuva.org (Jani Grönberg) writes:

> Romain Francoise <romain@orebokech.com> writes:
>
>> chardhros@spamtrap.oneccuva.org (Jani Grönberg) writes:
>>
>>> Before when I exit a group with "q" or "c", the cursor in group buffer
>>> was automatically changed to next group containing unread messages.
>>
>> Works here, and I don't see any recent change that could cause this...
>>
After experimentation, I have narrowed down the seeming cause of this
problem: This happens if the group buffer is visible when exiting the
summary buffer. This is not of course the default configuration, but I
like to use split screen. As I mentioned before, I did not encounter
this behaviour before gnus-20041125.

Is this a bug or has the behaviour of gnus-add-configuration somehow
changed? My setup is shamelessly copied and slightly modified from
this article:
http://groups-beta.google.com/group/gnu.emacs.gnus/msg/4436b5d9523408b1

//jani

-- 
A

Re: exiting summary buffer does not move cursor in group buffer any more

[Romain Francoise]

chardhros@spamtrap.oneccuva.org (Jani Grönberg) writes:

> After experimentation, I have narrowed down the seeming cause of this
> problem: This happens if the group buffer is visible when exiting the
> summary buffer.

Good catch, this is caused by the following change:

2004-11-22  Stefan Monnier  <monnier@iro.umontreal.ca>

	* gnus-sum.el (gnus-summary-exit): Remove redundant and harmful
	pop-to-buffer, covered by the subsequent gnus-configure-windows.

When the group buffer is already visible the value of point in the
buffer is now reset to the window's value when we reselect it; before
this change we called pop-to-buffer which displayed the group buffer in
the selected window (the one displaying the summary buffer) and ensured
that the move was taken into account...

I don't remember why Stefan made that change and why pop-to-buffer was
harmful here... let's CC him.

-- 
Romain Francoise <romain@orebokech.com> | The world is a fine place,
it's a miracle -- http://orebokech.com/ | and worth fighting for.
                                        | --Ernest Hemingway

Re: exiting summary buffer does not move cursor in group buffer any

[Stefan Monnier]

>> After experimentation, I have narrowed down the seeming cause of this
>> problem: This happens if the group buffer is visible when exiting the
>> summary buffer.

> Good catch, this is caused by the following change:

> 2004-11-22  Stefan Monnier  <monnier@iro.umontreal.ca>

> 	* gnus-sum.el (gnus-summary-exit): Remove redundant and harmful
> 	pop-to-buffer, covered by the subsequent gnus-configure-windows.

> When the group buffer is already visible the value of point in the
> buffer is now reset to the window's value when we reselect it; before
> this change we called pop-to-buffer which displayed the group buffer in
> the selected window (the one displaying the summary buffer) and ensured
> that the move was taken into account...

> I don't remember why Stefan made that change and why pop-to-buffer was
> harmful here... let's CC him.

When pop-to-frame is non-nil and the *Group* buffer is not visible,
pop-to-buffer creates a new frame and takes the careful window management
off-guard.

Does the patch below solve the problem?


        Stefan


--- gnus-sum.el	04 jan 2005 14:46:56 -0500	1.56
+++ gnus-sum.el	29 jan 2005 17:31:08 -0500	
@@ -6680,9 +6680,9 @@
       (set-buffer gnus-group-buffer)
       (if quit-config
 	  (gnus-handle-ephemeral-exit quit-config)
-	(goto-char group-point)
 	(unless leave-hidden
-	  (gnus-configure-windows 'group 'force)))
+	  (gnus-configure-windows 'group 'force))
+	(goto-char group-point))
       ;; Clear the current group name.
       (unless quit-config
 	(setq gnus-newsgroup-name nil)))))

Re: exiting summary buffer does not move cursor in group buffer any

[Romain Francoise]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Does the patch below solve the problem?

> --- gnus-sum.el	04 jan 2005 14:46:56 -0500	1.56
> +++ gnus-sum.el	29 jan 2005 17:31:08 -0500	
> @@ -6680,9 +6680,9 @@
>        (set-buffer gnus-group-buffer)
>        (if quit-config
>  	  (gnus-handle-ephemeral-exit quit-config)
> -	(goto-char group-point)
>  	(unless leave-hidden
> -	  (gnus-configure-windows 'group 'force)))
> +	  (gnus-configure-windows 'group 'force))
> +	(goto-char group-point))
>        ;; Clear the current group name.
>        (unless quit-config
>  	(setq gnus-newsgroup-name nil)))))

Yes.  It's obviously correct.

-- 
Romain Francoise <romain@orebokech.com> | When we were kids, we hated
it's a miracle -- http://orebokech.com/ | things our parents did.

Re: exiting summary buffer does not move cursor in group buffer any

[Stefan Monnier]

Any news?  Is the patch helping at all?


        Stefan


>>>>> "Stefan" == Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> After experimentation, I have narrowed down the seeming cause of this
>>> problem: This happens if the group buffer is visible when exiting the
>>> summary buffer.

>> Good catch, this is caused by the following change:

>> 2004-11-22  Stefan Monnier  <monnier@iro.umontreal.ca>

>> * gnus-sum.el (gnus-summary-exit): Remove redundant and harmful
>> pop-to-buffer, covered by the subsequent gnus-configure-windows.

>> When the group buffer is already visible the value of point in the
>> buffer is now reset to the window's value when we reselect it; before
>> this change we called pop-to-buffer which displayed the group buffer in
>> the selected window (the one displaying the summary buffer) and ensured
>> that the move was taken into account...

>> I don't remember why Stefan made that change and why pop-to-buffer was
>> harmful here... let's CC him.

> When pop-to-frame is non-nil and the *Group* buffer is not visible,
> pop-to-buffer creates a new frame and takes the careful window management
> off-guard.

> Does the patch below solve the problem?


>         Stefan


> --- gnus-sum.el	04 jan 2005 14:46:56 -0500	1.56
> +++ gnus-sum.el	29 jan 2005 17:31:08 -0500	
> @@ -6680,9 +6680,9 @@
>        (set-buffer gnus-group-buffer)
>        (if quit-config
>  	  (gnus-handle-ephemeral-exit quit-config)
> -	(goto-char group-point)
>  	(unless leave-hidden
> -	  (gnus-configure-windows 'group 'force)))
> +	  (gnus-configure-windows 'group 'force))
> +	(goto-char group-point))
>        ;; Clear the current group name.
>        (unless quit-config
>  	(setq gnus-newsgroup-name nil)))))

Re: exiting summary buffer does not move cursor in group buffer any

[Romain Francoise]

chardhros@spamtrap.oneccuva.org (Jani Grönberg) writes:

> - I rebooted the computer and thus restarted gnus (but I don't know
> why this should make a difference)

It shouldn't make any difference provided you byte-compiled the file
after patching.  If you just patched the source and eval'ed the
function, your running instance of Gnus had the fix but upon restart the
old byte-compiled version was used instead.  You can check for this
situation in the *Messages* buffer, look for something like ``Loading
foo (compiled; note, source file is newer)...done''.

-- 
Romain Francoise <romain@orebokech.com> | How long will it be before he
it's a miracle -- http://orebokech.com/ | sees you own his legs but his
                                        | mind is free?

Re: exiting summary buffer does not move cursor in group buffer any

[Jani Grönberg]

Romain Francoise <romain@orebokech.com> writes:

> It shouldn't make any difference provided you byte-compiled the file
> after patching.  

Right. Nor did the location, i.e. it worked just the same (=didn't
work) when I tried it at home. So the fix must have disappeared while
Gnus was running. 

I have now restarted it - it worked ok for about the first five groups
I selected, then it didn't work for a couple of groups, then it worked
for a group, didn't work for a few groups, worked again and now it
doesn't seem to work at all (tried about 15 groups). In other words,
the success rate seems to go down with passing of time (or number of
groups selected). This is strange indeed.

//jani

-- 
A