GNU bug report logs - #9006
24.0.50; Abort in unshow_buffer/kill-buffer

Previous Next

Full log

Message #59 received at 9006 <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 9006 <at> debbugs.gnu.org
Subject: Re: bug#9006: 24.0.50; Abort in unshow_buffer/kill-buffer
Date: Sun, 10 Jul 2011 12:25:23 +0200

On Sun, 10 Jul 2011 10:59:26 +0200 martin rudalics <rudalics <at> gmx.at> wrote:

>> I just encountered a bad effect that I assume is caused by this change,
>> since it didn't happen before:
>
> Before means before the change that sets w->pointm?  

Yes

>                                                      Are you sure it's
> not related to upgrading to the new window code?

Yes; I don't see the bad effect with my post-new-window-code build
without the w->pointm change.

>> when I type `h'
>> (gnus-summary-select-article-buffer) in the Gnus Summary buffer, this
>> splits the window and selects the Article buffer as it's supposed to,
>> but in the Summary buffer point simultaneously moves to point-min; it's
>> supposed to stay put.  The same thing happens when I have split windows
>> with the Summary and Article buffer and in the former type C-x o
>> (other-window).  I haven't been able to reproduce this with other
>> buffers, but only with Gnus Summary.  Still no abort, but this effect
>> means the fix -- if it is one -- at least needs further tuning.
>
> Just to make sure: This does not happen with the w->pointm hack?  

Correct.

>                                                                   If so,
> that is if it does not happen with the w->pointm hack, then it's
> obviously what I mentioned in the last post: We set window-point to 1
> for the temporary buffer but we don't reset it back to the old buffer's
> position upon exiting `vertical-motion'.  

Is window-point set to 1 as a side effect of making the temporary
buffer? 

>                                           Rather _you_ did set the old
> buffer's window point to 1 and it stays put there when you set w->buffer
> to old_buffer upon exiting `vertical-motion'.  

Do you have a suggestion how to reset point?

>                                                (Note that
> `vertical-motion' gets called by `split-window-above-each-other'.)

I don't see point moving when the window is split, only when -- with an
already split window -- the other window is selected.  Indeed, stepping
through both gnus-summary-select-article-buffer and other-window, I see
point move upon the call to select-window.  The comment at the top of
select_window seems relevant:

/* If select_window is called with inhibit_point_swap non-zero it will
   not store point of the old selected window's buffer back into that
   window's pointm slot.  This is needed by Fset_window_configuration to
   avoid that the display routine is called with selected_window set to
   Qnil causing a subsequent crash.  */

However, when I set a conditional breakpoint inhibit_point_swap!=0 this
did not interrupt execution, whereas with breakpoint select_window,
execution interrupts with inhibit_point_swap == 0, so I guess I don't
understand the comment.

Steve Berman

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.