Gnus development mailing list
 help / color / mirror / Atom feed
From: Katsumi Yamaoka <yamaoka@jpl.org>
To: ding@gnus.org
Subject: Re: gnus-article-read-summary-keys: can't handle hidden summary buffer?
Date: Mon, 29 Sep 2008 20:08:16 +0900	[thread overview]
Message-ID: <b4m1vz3tdjz.fsf@jpl.org> (raw)
In-Reply-To: <buovdwfvakg.fsf@dhapc248.dev.necel.com>

>>>>> 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, #<window 44>

> 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 52>)
>      window-buffer(#<window 52>)
>      (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,



  reply	other threads:[~2008-09-29 11:08 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-29  4:29 Miles Bader
2008-09-29 11:08 ` Katsumi Yamaoka [this message]
2008-09-29 12:20   ` Miles Bader
2008-09-29 23:55     ` Katsumi Yamaoka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b4m1vz3tdjz.fsf@jpl.org \
    --to=yamaoka@jpl.org \
    --cc=ding@gnus.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).