New option gnus-use-atomic-windows

New option gnus-use-atomic-windows

[Eric Abrahamsen]

Hi all,

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! 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.

Thanks,
Eric

Re: New option gnus-use-atomic-windows

[Eric S Fraga]

On Saturday, 21 Sep 2019 at 18:52, Eric Abrahamsen wrote:
> For those of you running master, there's a new option
> `gnus-use-atomic-windows' which you can play with. 

Thanks for the heads up.  Sounds useful!

> It defaults to nil, please set to t and test it! 

I've just built emacs and started it up.  gnus-use-atomic-windows seems
to default to t.
-- 
Eric S Fraga via Emacs 27.0.50 & org 9.2.4 on Debian bullseye/sid

Re: New option gnus-use-atomic-windows

[Eric Abrahamsen]

Eric S Fraga <e.fraga@ucl.ac.uk> writes:

> On Saturday, 21 Sep 2019 at 18:52, Eric Abrahamsen wrote:
>> For those of you running master, there's a new option
>> `gnus-use-atomic-windows' which you can play with. 
>
> Thanks for the heads up.  Sounds useful!
>
>> It defaults to nil, please set to t and test it! 
>
> I've just built emacs and started it up.  gnus-use-atomic-windows seems
> to default to t.

Well crap, you're right. That was a mistake. Hmm, I might just leave it
that way for now, to flush out bugs, and if there are more than a few
then change the default later. I need more sleep.

Re: New option gnus-use-atomic-windows

[Eric Abrahamsen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Eric S Fraga <e.fraga@ucl.ac.uk> writes:
>
>> On Saturday, 21 Sep 2019 at 18:52, Eric Abrahamsen wrote:
>>> For those of you running master, there's a new option
>>> `gnus-use-atomic-windows' which you can play with. 
>>
>> Thanks for the heads up.  Sounds useful!
>>
>>> It defaults to nil, please set to t and test it! 
>>
>> I've just built emacs and started it up.  gnus-use-atomic-windows seems
>> to default to t.
>
> Well crap, you're right. That was a mistake. Hmm, I might just leave it
> that way for now, to flush out bugs, and if there are more than a few
> then change the default later. I need more sleep.

Lars changed the default to nil, so we're back where we ought to be :)

Re: New option gnus-use-atomic-windows

[Sven Joachim]

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.

> 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.

Cheers,
       Sven

Re: New option gnus-use-atomic-windows

[Eric S Fraga]

I am struggling to see the advantage of gnus-use-atomic-windows.  Can
somebody (Eric?) illustrate a benefit (other than helm, as mentioned
earlier, which I don't use)?  In a day of testing so far, it has
gotten in the way...  Maybe (definitely) I'm missing the point.

thanks,
eric

-- 
Eric S Fraga via Emacs 27.0.50 & org 9.2.4 on Debian bullseye/sid

Re: New option gnus-use-atomic-windows

[Brent Busby]

Eric S Fraga <e.fraga@ucl.ac.uk> writes:

> I am struggling to see the advantage of gnus-use-atomic-windows.  Can
> somebody (Eric?) illustrate a benefit (other than helm, as mentioned
> earlier, which I don't use)?  In a day of testing so far, it has
> gotten in the way...  Maybe (definitely) I'm missing the point.

My two cents:

Probably the benefit is just that unlike almost any other Emacs
application, Gnus doesn't let you use windows (in the Emacs sense of the
word, not frames) to use it at the same time while you're also looking
at something else.  Any attempts to do that will be foiled just as soon
as you do just about anything in Gnus.  When I want to do that, I
usually just open a new frame so Gnus can have one dedicated to it, but
I'm running Emacs in X, so it's nice that I have frames.  If I were on a
VTY console, I'd have to just live with Gnus owning my whole display
when I'm using it.

gnus-use-atomic-windows seems to be an attempt to correct that, and let
Gnus share frame space nicely with the buffers of things that don't
belong to Gnus.  But we've been living with this for so long that we've
sort of adapted to things the way they have always been (typical Emacs
users, huh?), and thus gnus-use-atomic-windows brings its own problems.

Re: New option gnus-use-atomic-windows

[Eric S Fraga]

Yes, maybe.  I do tend to create a new frame semi-automatically any time
I want to do anything while reading gnus.  Frames are cheap and
non-intrusive when using a tiling WM (stumpwm in my case).  So maybe
atomic windows don't give me anything.  I'll keep it set just to see if
any positive use case appears to me in the meantime, however.

Thanks.
-- 
Eric S Fraga via Emacs 27.0.50 & org 9.2.4 on Debian bullseye/sid

Re: New option gnus-use-atomic-windows

[Eric Abrahamsen]

Brent Busby <brent@jfi.uchicago.edu> writes:

> Eric S Fraga <e.fraga@ucl.ac.uk> writes:
>
>> I am struggling to see the advantage of gnus-use-atomic-windows.  Can
>> somebody (Eric?) illustrate a benefit (other than helm, as mentioned
>> earlier, which I don't use)?  In a day of testing so far, it has
>> gotten in the way...  Maybe (definitely) I'm missing the point.
>
> My two cents:
>
> Probably the benefit is just that unlike almost any other Emacs
> application, Gnus doesn't let you use windows (in the Emacs sense of the
> word, not frames) to use it at the same time while you're also looking
> at something else.  Any attempts to do that will be foiled just as soon
> as you do just about anything in Gnus.  When I want to do that, I
> usually just open a new frame so Gnus can have one dedicated to it, but
> I'm running Emacs in X, so it's nice that I have frames.  If I were on a
> VTY console, I'd have to just live with Gnus owning my whole display
> when I'm using it.
>
> gnus-use-atomic-windows seems to be an attempt to correct that, and let
> Gnus share frame space nicely with the buffers of things that don't
> belong to Gnus.  But we've been living with this for so long that we've
> sort of adapted to things the way they have always been (typical Emacs
> users, huh?), and thus gnus-use-atomic-windows brings its own problems.

Yeah, that was the direction I was headed. Recent Emacs also have the
concept of "side windows", and I'm still hoping that some combination of
side windows and atomic windows can get us to a place where Gnus can
have its nicely-configured multi-window layout either occupying a whole
frame, or part of a frame, and other Emacs activities won't interfere
with that. But that will probably take a while to achieve.

Re: New option gnus-use-atomic-windows

[Eric Abrahamsen]

Eric S Fraga <e.fraga@ucl.ac.uk> writes:

> I am struggling to see the advantage of gnus-use-atomic-windows.  Can
> somebody (Eric?) illustrate a benefit (other than helm, as mentioned
> earlier, which I don't use)?  In a day of testing so far, it has
> gotten in the way...  Maybe (definitely) I'm missing the point.

Maybe it's most useful for Helm, after all! I see that the default
*Completions* buffer doesn't actually do what Helm does (squeeze the
pop-up buffer between the Summary and Article buffers), so there's no
advantage there. I was hoping that *Help* pop-up buffers would no longer
occupy one of Gnus' windows, but they still do, so that's no better
either.

Maybe the whole option isn't quite worth it...

Re: New option gnus-use-atomic-windows

[Eric S Fraga]

On Monday, 23 Sep 2019 at 11:34, Eric Abrahamsen wrote:
> I was hoping that *Help* pop-up buffers would no longer occupy one of
> Gnus' windows, but they still do, so that's no better either.

Ah, that's a good example.  It would indeed be good if a *Help* buffer
simply caused the other windows to shrink to allow the new window to
appear.  I now see where you are heading.

> Maybe the whole option isn't quite worth it...

It might be but it may also be the case that it's difficult to achieve.

-- 
Eric S Fraga via Emacs 27.0.50 & org 9.2.4 on Debian bullseye/sid

Re: New option gnus-use-atomic-windows

[dick]

> I am type C-x 1... finished reading an article

Aye, this pains me somewhat, and `q` would be better.

So the first `q` kills the split-pane of *Summary* and *Article*.  The
second `q` takes me back to *Group*.

Re: New option gnus-use-atomic-windows

[Eric Abrahamsen]

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.