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,
next prev parent 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).