From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stephen Berman Newsgroups: gmane.emacs.bugs Subject: bug#9006: 24.0.50; Abort in unshow_buffer/kill-buffer Date: Sun, 10 Jul 2011 12:25:23 +0200 Message-ID: <87d3hiqvos.fsf@escher.fritz.box> References: <877h7wxqjv.fsf@escher.fritz.box> <4E1429F3.1010305@gmx.at> <87oc17xlmu.fsf@escher.fritz.box> <4E156D17.8020804@gmx.at> <871uy2qvv6.fsf@escher.fritz.box> <4E15D520.4030809@gmx.at> <87mxgobcj6.fsf@escher.fritz.box> <4E1814F7.4060002@gmx.at> <87r55zekei.fsf@escher.fritz.box> <4E18510F.7070506@gmx.at> <87wrfrmnbv.fsf@escher.fritz.box> <87sjqfmm2n.fsf@escher.fritz.box> <4E1969EE.7040201@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1310293586 12451 80.91.229.12 (10 Jul 2011 10:26:26 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 10 Jul 2011 10:26:26 +0000 (UTC) Cc: 9006@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Jul 10 12:26:22 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QfrDQ-0007bn-Fh for geb-bug-gnu-emacs@m.gmane.org; Sun, 10 Jul 2011 12:26:20 +0200 Original-Received: from localhost ([::1]:41809 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QfrDP-00051C-FC for geb-bug-gnu-emacs@m.gmane.org; Sun, 10 Jul 2011 06:26:19 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:43647) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QfrDA-00050s-Mj for bug-gnu-emacs@gnu.org; Sun, 10 Jul 2011 06:26:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QfrD9-0003RI-Gd for bug-gnu-emacs@gnu.org; Sun, 10 Jul 2011 06:26:04 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:57841) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QfrD9-0003RB-EL for bug-gnu-emacs@gnu.org; Sun, 10 Jul 2011 06:26:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1QfrD8-0005ny-Gk; Sun, 10 Jul 2011 06:26:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stephen Berman Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 10 Jul 2011 10:26:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9006 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 9006-submit@debbugs.gnu.org id=B9006.131029353822284 (code B ref 9006); Sun, 10 Jul 2011 10:26:02 +0000 Original-Received: (at 9006) by debbugs.gnu.org; 10 Jul 2011 10:25:38 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QfrCi-0005nN-M2 for submit@debbugs.gnu.org; Sun, 10 Jul 2011 06:25:37 -0400 Original-Received: from mailout-de.gmx.net ([213.165.64.22]) by debbugs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1QfrCf-0005n9-Ft for 9006@debbugs.gnu.org; Sun, 10 Jul 2011 06:25:35 -0400 Original-Received: (qmail invoked by alias); 10 Jul 2011 10:25:26 -0000 Original-Received: from i59F57976.versanet.de (EHLO escher.home) [89.245.121.118] by mail.gmx.net (mp022) with SMTP; 10 Jul 2011 12:25:26 +0200 X-Authenticated: #20778731 X-Provags-ID: V01U2FsdGVkX19gWJAEbXVgKLgsdv0kAA+Aolx8S6Mw1J7oJQW48K QtjLl8C0WWKgBz Original-Received: by escher.home (Postfix, from userid 1000) id AD3185F912; Sun, 10 Jul 2011 12:25:23 +0200 (CEST) In-Reply-To: <4E1969EE.7040201@gmx.at> (martin rudalics's message of "Sun, 10 Jul 2011 10:59:26 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-Y-GMX-Trusted: 0 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Sun, 10 Jul 2011 06:26:02 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:48454 Archived-At: On Sun, 10 Jul 2011 10:59:26 +0200 martin rudalics 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