On Tue, May 13, 2014 at 03:42:05PM -0700, Keith Amling wrote: > > > Well, I agree it needs to be destroyed eventually but the issue is that > > > if a user thinks of the client as being set to [read from] a keytable > > > with a name then they will likely think binding a key into a keytable of > > > that name will be the same table even if the bind happens after the set. > > > > This will still work if the key table is a pointer, both the bind and > > the set will use the same key table. > > > > Or are you thinking of creating the table after running the set command? > > This shouldn't work - you shouldn't be able to set a client to a > > nonexistent table. > > I guess I don't super care what happens since I won't personally be > writing any switch-client -T into an empty table but I had assumed we > would allow switching to a new [and ephemeral] table since otherwise > switch-client -T can fail which just seems weird to me.
I'd say it should fail if the table doesn't exist. I can't think of a case where I would want it to automatically create a table, except to confuse people who make a typo in the table name. Do you have a use in mind? > In many ways it is a different view of things. I was thinking of key > bindings as now indexed by the table and the key rather than just the > key whereas the direction this patch is heading is that the table itself > as a map is an exposed part of the model rather than an implementation > detail. Yes I think it should be exposed, I think "key tables containing key bindings" is easier to understand than thinking of it as a sort of tag on the key, and it has the same effect really. > > That said, reiterate your commitment once more to failing switch-client > -T into an empty table and I'm happy to do it. > > > > My opinion about safety is completely countered by ref counting (it was > > > the final unbind's deletion having to know about and clean up > > > outstanding references from clients that was worrying me) and the > > > weirdness with stale keytables of duplicate names isn't that big of a > > > deal for the sanity we're gonna save in code. > > > > They don't need to know about the specific references from clients, they > > can check every client in the clients list. All clients will be in the > > list and nobody will have more than at most a few hundred so walking > > them all would be fine. > > > > Or reference counting the tables would work too if you prefer. > > Reference counting it is for sure. Performance wasn't really my > concern, the spooky ownership-at-a-distance was. It just seems fragile > for clients to hold a reference they don't really own and have the > actual owner (key-bindings.c) have to be aware of these extra > references. With reference counting it's entirely moot though. Sure, reference counting the tables is fine. Thanks ------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs _______________________________________________ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
