Hi
I don't have a lot of time right now, but here are some comments:
- What's the point of having key_binding_map_value and
key_binding_map_entry? Why not just one key_table struct?
key_bindings_remove can remove it from the tree and unref it, the
unref func can free it when it hits 0.
- A
> > > 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
> > 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
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
> nev
> There should be no need for a prefix key anymore. Instead, the default
> root table should have a binding for C-b to change the key table.
>
> That way the prefix table is not special, the only special table is the
> root table.
>
> (Although we'll need some compatibility goo to keep the prefix
On Sun, Apr 20, 2014 at 2:22 PM, Suraj Kurapati wrote:
> On Sun, Apr 20, 2014 at 12:38 AM, Nicholas Marriott wrote:
>> I don't want to have two ways to do directional movement of panes
>
> Fair enough. I can live with `selectp -L` to go from pane X to W. :)
Was this change committed? I'm using t
On Wed, Apr 23, 2014 at 3:33 AM, Thomas Adam wrote:
> for anyone who is currently tracking the SF Git version of tmux.
> I've just pushed a bunch of updates out which will result in the
> breakage of some people's configuration, namely:
>
> * The 'monitor-content' option is no longer available;
> *
They cause copy selection to exclude to the left (or right) of the
column when they're set. These are screen's version of block copy and I
think they do better than tmux's for copying e.g. the paths out of `git
status`:
> $ git status
> ...
> #
> # some/file
> # some/much/much/much/longer/file
>
Hmm, this was just something else I noticed missing when I found the
lack of c and C. I had already failed to make do with what tmux had in
the case of c/C so I didn't maybe try as hard as I could have with J.
I had focused on joining at copy time since it's what I was used to
coming from screen
> - What's the point of having key_binding_map_value and
> key_binding_map_entry? Why not just one key_table struct?
> key_bindings_remove can remove it from the tree and unref it, the
> unref func can free it when it hits 0.
>
> - Also if we just have key_table then key_binding_map could be
*) Merged key_binding_map_{value|entry}, now key_table
*) Renamed key_binding_map to key_tables
*) Fixed backward -n in unbind-key
*) Inlined/rearranged bind-key last three code paths
Keith
---
cmd-bind-key.c | 16 +--
cmd-list-keys.c | 80 +++
cmd-swit
11 matches
Mail list logo
