From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/67479 Path: news.gmane.org!not-for-mail From: Katsumi Yamaoka Newsgroups: gmane.emacs.gnus.general Subject: Re: gnus-article-read-summary-keys: can't handle hidden summary buffer? Date: Mon, 29 Sep 2008 20:08:16 +0900 Organization: Emacsen advocacy group Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1222686573 13152 80.91.229.12 (29 Sep 2008 11:09:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 29 Sep 2008 11:09:33 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M15930@lists.math.uh.edu Mon Sep 29 13:10:30 2008 connect(): Connection refused Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by lo.gmane.org with esmtp (Exim 4.50) id 1KkGdy-0000mj-5R for ding-account@gmane.org; Mon, 29 Sep 2008 13:10:22 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by util0.math.uh.edu with smtp (Exim 4.63) (envelope-from ) id 1KkGci-0003kQ-14; Mon, 29 Sep 2008 06:09:04 -0500 Original-Received: from mx1.math.uh.edu ([129.7.128.32]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1KkGcg-0003kA-Kw for ding@lists.math.uh.edu; Mon, 29 Sep 2008 06:09:02 -0500 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx1.math.uh.edu with esmtp (Exim 4.69) (envelope-from ) id 1KkGcd-0005ou-EH for ding@lists.math.uh.edu; Mon, 29 Sep 2008 06:09:02 -0500 Original-Received: from orlando.hostforweb.net ([216.246.45.90]) by quimby.gnus.org with esmtp (Exim 3.36 #1 (Debian)) id 1KkGci-0005dU-00 for ; Mon, 29 Sep 2008 13:09:04 +0200 Original-Received: from localhost ([127.0.0.1]:40743) by orlando.hostforweb.net with esmtpa (Exim 4.69) (envelope-from ) id 1KkGc5-0000YV-Az for ding@gnus.org; Mon, 29 Sep 2008 06:08:26 -0500 X-Hashcash: 1:20:080929:ding@gnus.org::5tygYBfMNiv+ORbS:0000Bm6e X-Face: #kKnN,xUnmKia.'[pp`;Omh}odZK)?7wQSl"4o04=EixTF+V[""w~iNbM9ZL+.b*_CxUmFk B#Fu[*?MZZH@IkN:!"\w%I_zt>[$nm7nQosZ<3eu;B:$Q_:p!',P.c0-_Cy[dz4oIpw0ESA^D*1Lw= L&i*6&( User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.60 (gnu/linux) Cancel-Lock: sha1:WmxKmLGPOFk3L1rtBFT95f79uuM= X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - orlando.hostforweb.net X-AntiAbuse: Original Domain - gnus.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jpl.org X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: -2.6 (--) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:67479 Archived-At: >>>>> Miles Bader wrote: > If I select the article window, and hide the summary buffer (something I > often like to do while reading long threads), then many inter-article > movement commands give an error like: > gnus-article-read-summary-keys: Wrong type argument: window-live-p, # > The commands still seem to pretty much do the right thing (for instance, > "n" still moves to the next message), but the constant error messages > are annoying (and presumably there are some minor functional differences > as well). > This used to work properly, with no error messages. I'm not really sure > when error messages started showing up, but sometime in the medium-past > (at least the last year or so I think?). > The stack backtrace is: > Debugger entered--Lisp error: (wrong-type-argument window-live-p #) > window-buffer(#) > (set-buffer (window-buffer win)) ^^^ [...] > gnus-article-read-summary-keys(nil) > call-interactively(gnus-article-read-summary-keys nil nil) > Thanks, I couldn't reproduce it but I can imagine it is possible to happen. Even in the case where the summary buffer is hidden, the summary window appears a moment (it is necessary for running a summary command) and the window `win' is set to it at that time. After the summary window is hidden again, in my case `win' points to the window in which there is the article buffer (i.e. `win' is still alive but the buffer which the window visits is changed from the summary buffer). However, it is possible that `win' points to non-existent window for some reason. It might be due to user's hook function, a customized window configuration, or other. So I think it should be checked whether it exists. Could you test this patch? --- gnus-art.el~ 2008-08-11 22:24:20 +0000 +++ gnus-art.el 2008-09-29 11:06:22 +0000 @@ -6373,6 +6373,7 @@ (point)))) (when (and (not not-restore-window) new-sum-point + (window-live-p win) (with-current-buffer (window-buffer win) (eq major-mode 'gnus-summary-mode))) (set-window-point win new-sum-point) (Anyway there still be some codes of which the uses are unknown in `gnus-article-read-summary-keys', though.) Regards,