Re: [dev] dvtm: don't change master or numbering

From: Greg Reagle <>
Date: Fri, 22 May 2015 18:13:25 -0400

On Fri, May 22, 2015, at 05:31 PM, Ross Mohn wrote:
> I don't think this should be mainline workflow, but it probably makes a
> nice patch. However, you should understand that window numbering is
> always the same with the master being window #1 and the rest in
> consecutive order. The clients are then arranged within those
> pre-numbered windows, The clients can move around to different window
> positions, but the window numbers stay the same. When you minimize a
> window, it takes its client with it and moves to the end of the stack.
> When you unminimize a window, it pops up to the master (#1), bringing
> its client along, and pushes the other clients down the stack.

Thanks for that explanation. In that case my patch is seriously flawed,
because it screws up the window numbers.

I've written another patch that does it a bit differently, it creates
new clients as the second window, so it preserves the master as master
(as I want), and it doesn't screw up the window numbering. However, it
still does gratuitous renumbering.

What I really want is more stability. When I have mutt (or whatever)
running in my master window, I want it to stay as my master window
unless I tell dvtm explicitly to change the master window. This means I
don't want newly created clients to automatically take the master
window, and I don't want un-minimized clients to automatically take the
master window.

Another stability goal is that I don't want every client shifting its
windows number by one, unless I explicitly tell dvtm to do so. So if I
create a new window or un-minimize a window, I'd like it to be placed as
the last visible window so that no visible clients need to change their
window number. Of course if I choose to Mod-Enter, I know that
re-numbering will be required, there's no getting around that.

Based on what I understand currently of the internals of dvtm (which is
not a lot and maybe somewhat confused), I would like newly created
clients and un-minimized clients to go after the last visible window.
This way the master stays the master and all the visible clients keep
their window number. Does that make sense?

So I'm thinking that I need to write an attach function that will attach
a client after the last visible window and before the first minimized
window, and call that for newly created and un-minimized clients. Is
that the solution?

-- - Access your email from home and the web
Received on Sat May 23 2015 - 00:13:25 CEST

This archive was generated by hypermail 2.3.0 : Sat May 23 2015 - 00:24:07 CEST