Re: Understanding atomic window groups

[martin rudalics]

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

I consider making and dissolving atomic windows rather specific to
Gnus and it should be probaly done there.  Only if there is a more
general need, such functionality should be provided by window.el.

> 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 can add it any time.

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

Is BBDB something typical for Gnus?  I thought the "group" window is
the more typical one.  Or maybe the ones for composing messages or
articles.

> Gnus has many buffers (see `gnus-window-to-buffer'), and many potential
> window configurations (the manual lists 22 known possibilities).

Where is all that documented?  'gnus-window-to-buffer', for example?
I suppose the 22 possibilities are the ones from section 9.5.1 of the
Gnus manual.  So probably I get some predefined hardcoded layout when
doing, say 'gnus-summary-edit-article' and when done with editing the
previous layout gets restored.  But where is that described?  And how
can I customize it?

Looking at section 9.5 Window Layout: It starts with saying that there
are glitches with 'gnus-use-full-window' (which should probably be
called 'gnus-use-full-frame').  But wouldn't embedding Gnus' windows
in an Emacs frame be one of the primary tasks of the layout mechanism?

Next it says that ‘gnus-buffer-configuration’ describes how much space
each Gnus buffer should be given.  IMO it should rather say how much
space a window like the "summary window" or "article window" are
given.  Below it even talks about "splitting buffers" ...

Also, a sentence like "In a ‘frame’ split, the last subsplit having a
leaf split where the tag ‘frame-focus’ is a member ..." is very hard
to comprehend - I failed.

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

I don't think that specifying layouts operationally via "vertical" and
"horizontal" splits is bad per se and people are most likely used to
it.  But I think that some descriptive layer maybe on top of the
operational one using terms like "top", "above" or "right" would be
more suitable for people using Gnus for the first time.  In either
case I failed to decipher the layout sketched in section 9.5.2 from
the two (why two?) accompanying 'gnus-add-configuration' calls.

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

I would like to see a comprehensible and more complete documentation
of Gnus' windows layouts first.  Then we could talk about an
alternative, less operational specification of the layout and how to
support it with the help of Emacs' core functions.

Thanks, martin