From: Eric Abrahamsen <eric@ericabrahamsen.net>
To: ding@gnus.org
Subject: Re: New option gnus-use-atomic-windows
Date: Mon, 23 Sep 2019 11:30:12 -0700 [thread overview]
Message-ID: <87lfuekgqz.fsf@ericabrahamsen.net> (raw)
In-Reply-To: <87ef08ywmj.fsf@turtle.gmx.de>
Sven Joachim <svenjoac@gmx.de> writes:
> On 2019-09-21 18:52 -0700, Eric Abrahamsen wrote:
>
>> For those of you running master, there's a new option
>> `gnus-use-atomic-windows' which you can play with. You can read about
>> atomic windows in the Elisp manual, but the basic idea is that a Gnus
>> layout of several windows will be treated as a *single* window by code
>> that pops up buffers in new windows. For example, if you're using Helm
>> and a Helm completion buffer pops up while you're in the Summary, that
>> completion buffer will show up on the bottom or to the right of the
>> entire Gnus window composition, and not squished between the Summary and
>> Article buffers.
>>
>> It defaults to nil, please set to t and test it!
>
> As has already been said, it actually defaults to t, so I was "forced"
> to test it.
Sorry about that -- the default has now been set properly to nil, so you
can remove any customization.
>
>> I'm particularly
>> interested in any third-party code that uses `delete-other-windows' from
>> a Gnus window. Code like that will now signal an error (because by
>> default atomic windows can't be individually deleted) which reads:
>>
>> "Root of atomic window is root window of its frame"
>>
>> If you get that, please let me know. It is solvable, but I'd like to see
>> what kind of code is using this before putting a fix in.
>
> For me it is not third-party code which uses `delete-other-windows',
> rather I am typing C-x 1 myself routinely in the summary buffer when I
> have finished reading an article. That this signals an error now is
> highly annoying, and I set gnus-use-atomic-windows to nil as soon as I
> discovered that option.
Okay, good to know. I have always used "=" for that, so I guess I didn't
run into it. These kinds of misbehavior are fixable, but I guess it
depends on whether the whole thing is worth fixing.
prev parent reply other threads:[~2019-09-23 18:30 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-22 1:52 Eric Abrahamsen
2019-09-22 17:37 ` Eric S Fraga
2019-09-22 17:47 ` Eric Abrahamsen
2019-09-23 1:54 ` Eric Abrahamsen
2019-09-22 19:11 ` Sven Joachim
2019-09-23 15:55 ` Eric S Fraga
2019-09-23 17:13 ` Brent Busby
2019-09-23 17:26 ` Eric S Fraga
2019-09-23 18:39 ` Eric Abrahamsen
2019-09-23 18:34 ` Eric Abrahamsen
2019-09-23 20:23 ` Eric S Fraga
2019-09-23 16:34 ` dick
2019-09-23 18:30 ` Eric Abrahamsen [this message]
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=87lfuekgqz.fsf@ericabrahamsen.net \
--to=eric@ericabrahamsen.net \
--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).