Re: Understanding atomic window groups

[Eric Abrahamsen]

Eric Abrahamsen <address@hidden> writes:

> martin rudalics <address@hidden> writes:
>
>>> `quit-window' just behaved unpredictably.
>>
>> The idea behind `quit-window' is that it should _never_ bark at the
>> user but silently use the next-best solution when the predefined one
>> fails.  For example, typing C-h m usually displays a new *Help*
>> window.  Typing 'q' in that window conceptually deletes that window
>> because it did not exist before showing *Help*.  But if you do C-x 1
>> in the *Help* window first and then type 'q', that window can't be
>> deleted and thus will have to show some other buffer instead.
>
> 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.

For instance! Side windows have `window-toggle-side-windows', maybe we
could have something similar for atomic windows?

[...]

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

As a lazy developer, I'd like to be able to pull apart the setting
above, find the window with 'point and make that the "main window", and
use the rest of the information to issue a series of (probably)
`display-buffer-in-side-window' calls that put the rest of the windows
in place. It would be particularly nice if we could stick an 'atomic key
in the above setting, and have the resulting side window assembly be
atomic.

Maybe this is totally possible right now, I don't know.

Eric