emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debbugs-tracker] bug#29696: closed (Reading summary keys from article c


From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#29696: closed (Reading summary keys from article changes window configuration)
Date: Thu, 14 Dec 2017 04:47:02 +0000

Your message dated Thu, 14 Dec 2017 13:45:57 +0900
with message-id <address@hidden>
and subject line Re: bug#29696: Reading summary keys from article changes 
window configuration
has caused the debbugs.gnu.org bug report #29696,
regarding Reading summary keys from article changes window configuration
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
29696: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=29696
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: Reading summary keys from article changes window configuration Date: Wed, 13 Dec 2017 20:24:43 +0000 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Attachment: 0001-Do-not-pop-to-buffer-for-reading-gnus-summary-keys.patch
Description: Text Data

Using Gnus with the user option pop-up-frames set to 'graphic-only, I
observe the following behaviour:

1. Visit an article.
2. Make article window the sole window in its containing frame.
3. Type = (gnus-summary-expand-window).

Expected result: The article's summary replaces the article in the
frame's sole window.

Actual result: The expected result plus an additional frame displaying
the corresponding summary buffer.  In other words, expanding the article
window causes an extraneous frame to be created.

I believe this is caused by a call to pop-to-buffer within
save-window-excursion in the function gnus-article-read-summary-keys.
Is the call to pop-to-buffer really necessary for the purpose of key
lookup?  Wouldn't changing the current buffer suffice, so as not to
affect the window configuration in the first place?

If so, please consider the attached patch which addresses this.  The
docstring of save-window-excursion even warns of the possibility of
behaviour like the one I describe.

The information gathered by gnus-bug follows my signature.

Thanks,

-- 
Basil

Gnus v5.13
GNU Emacs 27.0.50 (build 9, x86_64-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2017-12-05

--- End Message ---
--- Begin Message --- Subject: Re: bug#29696: Reading summary keys from article changes window configuration Date: Thu, 14 Dec 2017 13:45:57 +0900 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (i686-pc-cygwin)
On Wed, 13 Dec 2017 20:24:43 +0000, Basil L. Contovounesios wrote:
> Using Gnus with the user option pop-up-frames set to 'graphic-only, I
> observe the following behaviour:

> 1. Visit an article.
> 2. Make article window the sole window in its containing frame.
> 3. Type = (gnus-summary-expand-window).

> Expected result: The article's summary replaces the article in the
> frame's sole window.

> Actual result: The expected result plus an additional frame displaying
> the corresponding summary buffer.  In other words, expanding the article
> window causes an extraneous frame to be created.

Confirmed and applied your patch in the emacs-26 branch.  Thanks.

> I believe this is caused by a call to pop-to-buffer within
> save-window-excursion in the function gnus-article-read-summary-keys.
> Is the call to pop-to-buffer really necessary for the purpose of key
> lookup?  Wouldn't changing the current buffer suffice, so as not to
> affect the window configuration in the first place?

I agree, only changing the buffer is sufficient in that case.
I don't know why pop-to-buffer is used, but it seems to be there
from the beginning (it is as is in Red Gnus 0.01 of 1996).
I guess it was beyond imagination that pop-to-buffer may raise
a new frame when there is no frame visiting the buffer, and why
this wasn't discovered so far is that those who set pop-up-frames
to nin-nil normally are not so many.

> If so, please consider the attached patch which addresses this.  The
> docstring of save-window-excursion even warns of the possibility of
> behaviour like the one I describe.

> The information gathered by gnus-bug follows my signature.

> Thanks,


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]