*) 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
> - 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
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
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
>
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;
> *
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
> > > 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
> 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
> > 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
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
11 matches
Mail list logo
