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 <am...@asmblr.net> wrote: > > On Mon, 22 Oct 2018 20:21:16 -0500 > Ethan Warth <redyoshi...@gmail.com> 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
