Re: Understanding atomic window groups

[Eric Abrahamsen]

On 06/03/19 11:12 AM, martin rudalics wrote:
>> Okay, I do see that `quit-window' has a more complicated job to do, and
>> multiple conditions are checked. I guess I was hoping/expecting that
>> `quit-window' in a member of an atomic window group could somehow be
>> altered to act on the whole group, rather than just the current window.
>
> We would have to specify the respective semantics first.  Atomic
> groups by default do not have main windows.  All its constituting live
> windows are treated equal - as, for example, two side-by-side windows
> showing the diffs of a file.  If we want to designate one constituent
> of an atomic window as the "main" window and have 'quit-window' act on
> the entire group as the 'quit-restore' parameter of that main window
> says, we would have to write specific code for 'quit-restore-window'.

No, that's probably not worth it.

>> I would at least add the fact that atomic groups can be nested,
>
> When I first used the term "nested" I only meant that an atomic window
> can comprise an arbitrary number of windows as long as the resulting
> window has a rectangular shape.  That's why I asked you to act on the
> root of the atomic window instead on the parent of one of its
> constituents.  I'm not sure what to say more about this in the manual
> - maybe you can propose the necessary change.

I was misunderstanding what you meant by "nested".

>> and say
>> something about how to get _rid_ of an atomic group. When I was first
>> experimenting, I ended up having to reboot emacs, because I couldn't
>> figure out how to un-atomic the frame.
>
> I tried to say that now.
>
>> It would be great to have more examples in the side windows section as
>> well. The two features together feel like they could be very powerful,
>> there's just a bit of a documentation gap.
>
> I already devote an entire subsection to an example.

The new docs look great, and clear up quite a few of my confusions,
thank you.

>> I've had it in the back of my mind to try replacing Gnus' homemade
>> windowing functionality with side windows, because they do pretty much
>> the same thing, but I'm not sure where to start. In particular, the doc
>> examples show a setup where certain buffers appear to _always_ be
>> displayed in certain side buffers. My assumption is that in the vast
>> majority of cases, people would want to display _this_ particular group
>> of buffers in a certain way on _this_ frame, and not pollute the global
>> config.
>
> Which use case do you have in mind?  The people asking before for such
> a feature wanted the layout apply to any frame - that is, side windows
> should specify the global configuration.

I'll answer this below.

On 06/03/19 11:13 AM, martin rudalics wrote:
>> For instance! Side windows have `window-toggle-side-windows', maybe we
>> could have something similar for atomic windows?
>
> 'window-toggle-side-windows' was a specific wish of people of the
> people who wanted an IDE-like environment.  As for atomic windows do
> you mean something like "make an atomic window occupy the main window
> of its frame" and restore the remaining windows when toggling again?

I was thinking the toggle would first remove the atomic property from a
group of windows and record the fact that they used to be atomic. The
next call would restore that atomicity. But... recording _how_ they were
arranged, and restoring them when the entire frame has possibly been
rearranged in the meantime, sounds onerous and weird.

Maybe the `window-dissolve-atom' function you posted above would be
enough. It's not terribly mysterious code, but it is a very useful
utility function, particularly for people who are just getting into
this.

>>> I've had it in the back of my mind to try replacing Gnus' homemade
>>> windowing functionality with side windows, because they do pretty much
>>> the same thing, but I'm not sure where to start.
>>
>> Just to extend this hypothetical:
>>
>> Gnus configures its various window layouts in
>> `gnus-buffer-configuration', an assoc list where each element looks
>> like:
>>
>> (article
>>    (horizontal 1.0
>>      (vertical 0.5
>>        (group 1.0))
>>      (vertical 1.0
>>        (summary 0.25 point)
>>        (article 1.0))))
>>
>> This configuration is selected using 'article as a key --
>> (gnus-configure-windows 'article) -- the rest of it is arbitrarily
>> nested instructions about how to split the various buffer and how big
>> the splits should be.
>
> I'd need more information of the type what kind of windows you want to
> show and how they should be laid out on a frame.  The basic idea of
> side windows was that there are main windows where the user is editing
> and side windows where additional information is shown.  How would
> that relate to gnus?

The typical example looks like:

+------------------------------+
|  Summary                     |
|                              |
+-------------------+----------+-
|                   |          |
|  Article          |  BBDB    |
|                   |          |
|                   |          |
+-------------------+----------+

Where point is in the Summary window -- that's the "main" window. It's
possible to put point in the Article or BBDB windows and do things
there, but the Summary keymap contains all kinds of bindings for
operating on the other two windows "remotely".

Gnus has many buffers (see `gnus-window-to-buffer'), and many potential
window configurations (the manual lists 22 known possibilities). The
same buffers might be displayed in different locations in different
configurations, which is why the `display-buffer-alist' approach doesn't
seem to fit.

It's possible that (as is often the case) Gnus' mechanisms are too
idiosyncratic to be recreated with built-in tools. If so, that's totally
fine -- I just thought that, if it were possible, it would be a nice
refactor.

Thanks again for the docs!
Eric