Re: [screen-devel] Window group code contribution

[Ethan Warth]

I use window groups in my .screenrc.  Window groups, as you likely already know,
can be used to group other child windows (including other child window groups)
together.  Window groups do /not/ have their own corresponding shell, though;
when you switch to a window group's window, you instead see the output of a
windowlist command (as a consequence, that group window's children are listed,
and can then be selected from).

Windowlist has two toggles that affect its output: the list can be sorted in
either index or MRU order, and the list can contain either just immediate
children windows of all descendant windows.  Since window groups use the same
code for their own output, they also support these toggles.

However, in the current code base, these toggles are reset to index ordering and
display of immediate children only every time a particular window group is
swapped out of and back into a pane.  To instead make these display settings
persist under such conditions on a per-window group basis, I made the
following code changes:

* I added two state booleans to the window structure to represent MRU ordering
and recursive descendant listing for window groups (and added values for these
two booleans to statically defined window structs in the code).
* I made the windowlist initialization function ignore the passed in order flags
if the windowlist is being generated for a window group, and I made the function
instead use the window group's stored flags.
* I made the sections of code that change the aforementioned flags for an active
windowlist also change those flags for the corresponding window group (in the
case that one exists, i.e., when the windowlist is being displayed as the
window group's output on a pane).

I tried to make the commit title sufficiently descriptive for the change, but
I'm open to alternatives for such a description.  I have also confirmed the
trailing whitespace instances that you have alluded to in your response.  I'm
more than happy to submit modified patches to reflect both the potential
commit description change and the removal of the trailing whitespaces; just
let me know what (if anything) the first commit's description should be
changed to.


Perfect normality is impossible.  Be unique!
   ―redyoshi49q


On Thu, Nov 1, 2018 at 3:08 PM Amadeusz Sławiński <address@hidden> wrote:
>
> On Mon, 22 Oct 2018 20:21:16 -0500
> Ethan Warth <address@hidden> wrote:
>
> > (I'm resending this, to the mailing list this time.  I didn't notice that my
> > reply wasn't actually going to the list.)
> >
> >
> > Sorry; your message ended up in my spam folder, and I didn't notice it
> > immediately.
> >
> > I will be including the git format-patch (both as inline text in this 
> > message
> > and also as file attachments as a redundancy measure).  This is my first 
> > time
> > submitting git patches over email; let me know if I need to make another
> > attempt at sending the commit patches.
> >
>
> Hi,
>
> sorry for delay, few things:
>
> Can you describe, what is a goal of first patch? I've read it few times
> and am a bit unsure. You can describe workflow which it fixes,
> preferably it should be also included in commit message, so if someone
> looks at commit later they know what it is about.
>
> There also seems to be few leftover whitespace characters at end of
> lines in first and second patch, you should be able to see them using
> "git show" command, they will be colored in red.
>
> Cheers,
> Amadeusz