Re: Understanding atomic window groups

[Eric Abrahamsen <eric@ericabrahamsen.net>]

martin rudalics <rudalics@gmx.at> writes:

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

I can mention that this only takes effect when `gnus-configure-windows'
is called. I'm not sure saving window state will be so useful: you might
say a particular layout describes the relationship of the group, summary
and article buffers, but the actual summary and article buffers will
change continuously.

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

Okay. That can wait until later.

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

Yup, that would probably be a better name.

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

In theory any key could be added to the alist, specifying any random
window layout, but nothing would ever call that code. A user could write
a function that calls `gnus-configure-windows' with their own symbol,
but if they know to do that, I doubt these docs would stop them.

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

I don't know, tbh. The two possibilities describe the same state,
arrived at by different means. By that token you might want to
distinguish between "group layout after starting Gnus" from "group
layout after exiting a summary buffer". Maybe that would be desirable,
but I haven't thought much about it.

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

Oops, thanks for the catch. Yes, this should be more careful to
distinguish between a split (which might contain further splits) and a
layout (a top-level collection of splits).

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

Yup, we could change this to 'select (and look for both, for backward
compatibility).

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

I think it is, at least implicitly... The existing docs mention that
splitting by absolute line/column values might be imprecise (might be
overridden by min/max window size specifications, or thrown off by
rounding). So there needs to be a window where we can say "any
imprecision will be rectified by adjusting this window". It would be
awkward to use multiple windows to do that. We could have an implicit
rule saying that the last window in a split might be subject to
adjustment.

In side-window terms, I suppose the 100% window could be considered the
"main" window, in that its size isn't explicit: it's just whatever is
left over after the other windows have been placed appropriately. But
"main" might also imply selection (?), in which case the analogy doesn't
work.

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

Good question. I suppose if the user has manually adjusted a layout,
they might not want Gnus to disturb that if it is functionally the same
as the defined layout. But I really don't know. It doesn't seem very
useful to me, either.

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

Could be... We'd have to translate buffers back to windows using
`gnus-window-to-buffer', then reconstruct the current window config into
the "split" format, and put that layout into
`gnus-buffer-configuration'. But that would only work for the current
session. I guess I don't quite see the utility, unless I'm
misunderstanding what you mean?

Thanks for the review!

Eric