The various things I didn't quote are all straight-forward and will be my pleasure to fix.
> I don't think it'd be that much compatibility code. > > We could just maintain a flag for the "option-set" prefix in the root > table, and that can be used for prefix/send-prefix. The root table can > never be deleted so that isn't an issue. > > prefix2 can go away once there is an alternative. > > Still, if you want to make the other changes first I will look again and > we can decide on this later. Sorry, I'm obviously falling behind here; I just don't follow what you're proposing with enough clarity to implement it. Are you suggesting another KEYC_* flag (or two?) for "this is the binding set by `set-option prefix[2]`"? Are you proposing an extra field (or two?) in key_bindings to hold the prefix in the root table? I don't mean to be a drag and I'd rather do what I can to minimize your work explaining your vision to chumps and/or having to clean up our crappy patches but I'm just not following this one. I'll clean the patch up for the other stuff first anyway. > > > - I think it would be better to point the client to a struct > > > key_bindings, not to a string with the name. I know it won't save the > > > lookup but it's neater than doing xstrdup/free all over the > > > place. When a table is deleted you can walk the clients and reset them > > > (or alternatively, reference count). > > > > I agree xstrdup/free all over the place is a mess but keeping a pointer > > to an actual table seems like an accident waiting to happen in terms of > > safety. > > You could say this about any pointer. > > > Additionally it provides weirdness if e.g. a user sets a > > keytable, then unbinds the last key in the keytable and rebinds it > > (causing the client to point to a stale empty keytable). > > I don't see that this will be able to happen - when the user unbinds the > last key the table needs to be destroyed, at that point the client > should be fixed up (or the table destroy deferred until the client is > finished with it). 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. 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. Keith ------------------------------------------------------------------------------ "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
