Re: Understanding atomic window groups

[Eric Abrahamsen]

martin rudalics <address@hidden> writes:

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

Sounds reasonable -- I'm the only one who's complained about this so
far, anyway. Let's leave it for now.

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

They're all typical! Just different layouts for different tasks. The
"group" layout is for browsing your groups and finding new mail, but
when you enter a group and select an article you often get something
like the above (the "article" layout). And yes, having BBDB visible is
very common, both in the "article" layout and the "message"
(composition) layout.

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

All the layouts are stored in `gnus-buffer-configuration'. It comes with
defaults, and you can mangle it however you please. The layouts are
selected with `gnus-configure-frame'.

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

I think most people just let Gnus take up a whole frame.

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

Yup, the docs try pretty hard, but it's quite confusing. I'd be curious
to know how many people are actually using its more complex features,
like frame splits or putting in frame parameters instead of a simple
sizing float.

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

`gnus-add-configuration' is just a convenience function for setting the
configuration of one "key" -- in that case the "summary" and "article"
keys. The ASCII art only depicts the first (article) layout, the summary
layout would be the same, but without the article window.

The configuration format is confusing to look at, but I do think it's
fine given the level of configurability the system is going for.

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

I can probably take a whack at improving the docs. To be clear, though,
this is just an idea I had -- I haven't asked anyone if they actually
want this, or run it by Lars or anything. But if changes are
backwards-compatible, configuration-wise, and simply result in a net
removal of code, that should be fine. I'll try to get to the docs this
weekend.

Thanks,
Eric