Re: Understanding atomic window groups

[martin rudalics]

> I've had a whack at updating the manual, and attached a diff. This is
> obviously just a first try, and I imagine there will be much that needs
> to be tweaked. To be honest, several of the examples in the manual
> didn't work as advertised when I tried them, but I guess that's a
> separate problem -- this is how it's _supposed_ to work, I think.

Thanks.

> - As you mentioned, `gnus-use-full-window' should be obsoleted in favor
>    of `gnus-use-full-frame'.

You should also specify _when_ things (liek the value of this
variable) take effect.  Note that with "window states" (Elisp manual
section 28.26) users should be able to save specific gnus layouts and
put them back into arbitrary windows, so maybe this variable is not so
important in the first place.

> - It would be nice if the size spec also accepted the symbol `fit',
>    which would trigger a `fit-window-to-buffer'.

'fit-window-to-buffer' might be hairy sometimes - triggered too often
it can be noisy and fitting adjacent windows can inherently cause
conflicts.  Maybe you also want some sort of fallback size when
fitting fails.


Some loose remarks on your changes and what they change:


'gnus-buffer-configuration' really means 'gnus-window-configuration'
although it's not a window configuration in the Emacs sense - maybe
'gnus-windows-layout' would be better.


The @dfn{key} is a symbol that names some action or
other.  For instance, when displaying the group buffer, the window
configuration function will use @code{group} as the key.  A full list of
possible names is listed below.

Why this restriction to "possible names"?  What if a user wants to
switch between two layouts both comprising the group buffer?  Below
you then say "the @code{message} key is used for both
@code{gnus-group-mail} and @code{gnus-summary-mail-other-window}.  If
it is desirable to distinguish between the two, something like this
might be used" which IIUC means that the same symbol might name two
different layouts?  Is that a good idea?


"The @dfn{value} (i.e., the @dfn{split}) says says which buffers to"
has one "says" to many.  Also, since it's much more than a split I
would use a term like "layout" instead.  Below you also talk about
sub-splits/subsplits which somehow increase the confusion.


Point will be put in the buffer that has the optional third element
@code{point}.

"Point" is inappropriate here.  IIUC this just specifies the window to
select.


At each level of split depth, there @emph{must} be one and only one
element that has the 100% tag.

Is that restriction really needed?


If all buffers mentioned in the configuration are already visible,
Gnus won't change the window configuration.  If you always want to
force the ``right'' window configuration, you can set

Why is this useful and in which occasions does it apply?


Finally, it seems that there is no way to "save back" into
'gnus-buffer-configuration' a layout that has been obtained by
"manually" changing an existing layout.  Right?  Wouldn't that be
desirable?


martin