Nicholas Marriott writes:
> --- status.c 15 Nov 2011 23:34:12 - 1.81
> +++ status.c 27 Nov 2011 03:09:56 -
> @@ -1156,11 +1156,8 @@ status_prompt_key(struct client *c, int
> /* Find the separator at the end of the word. */
> while (c->prompt_index != si
Hmm yes this is wrong for emacs and doesn't match what tmux does for 'e'
in vi mode either. So we need to do this and then if desired fix vi mode
in both so they work like vi:
Index: status.c
===
RCS file: /cvs/src/usr.bin/tmux/status
Ben Boeckel writes:
> Is M-f the same as 'e' in vi (end of next word)?
Yes, the only difference is where it leaves the cursor.
> I suppose that the same logic that copy mode is now doing to
> differentiate the two could be done there.
Actually the copy mode implementation is wrong too: in vi m
On Fri, Nov 25, 2011 at 18:32:40 +0100, Romain Francoise wrote:
> Did you test this patch series in emacs editing mode? M-f doesn't behave
> as it should, I'd expect it to move the cursor *after* the current word
> but it goes back to the last letter. This is inconsistent with the
> existing copy-m
Hi Ben,
Did you test this patch series in emacs editing mode? M-f doesn't behave
as it should, I'd expect it to move the cursor *after* the current word
but it goes back to the last letter. This is inconsistent with the
existing copy-mode implementation (and Emacs, readline, etc).
Thanks,
--
Rom
I fixed this:
> + word_separators =
> + options_get_string(&c->session, "word-separators");
Apart from that, looks fine, applied. Thanks!
On Fri, Nov 11, 2011 at 04:51:27PM -0500, Ben Boeckel wrote:
> On Mon, Oct 24, 2011 at 13:11:06 -0400, Ben Boeckel wrote:
> > On
On Mon, Oct 24, 2011 at 13:11:06 -0400, Ben Boeckel wrote:
> On Sun, Oct 23, 2011 at 02:19:50 +0100, Nicholas Marriott wrote:
> > I know we want an excuse to add client options but I'm not convinced
> > this should be it - none of the mode options or key bindings or whatnot
> > are per client and i
On Sun, Oct 23, 2011 at 02:19:50 +0100, Nicholas Marriott wrote:
> I know we want an excuse to add client options but I'm not convinced
> this should be it - none of the mode options or key bindings or whatnot
> are per client and it seems confusing to have two word-separators
> options. Can't it u
I know we want an excuse to add client options but I'm not convinced
this should be it - none of the mode options or key bindings or whatnot
are per client and it seems confusing to have two word-separators
options. Can't it use the existing session option?
On Thu, Oct 20, 2011 at 02:39:43PM -040
On Thu, Oct 20, 2011 at 12:17:48 -0400, Ben Boeckel wrote:
> In order to do this, I added options for clients (currently just
> word-separators) and the associated commands and documentation for them.
> This is done in the first patch.
Fixing some whitespace in the man page.
--Ben
From 60e5e44fd0
On Thu, Oct 20, 2011 at 12:17:48 -0400, Ben Boeckel wrote:
> @@ -64,7 +75,7 @@ cmd_show_options_exec(struct cmd *self, struct cmd_ctx *ctx)
> oo = &global_options;
> table = server_options_table;
> } else if (args_has(self->args, 'w') ||
> - self->entry ==
Hi,
I also implemented word motion actions for editing at the command
prompt. These patches are (or at least should be; a git merge is clean)
independent of the pane_index format patches I posted earlier.
In order to do this, I added options for clients (currently just
word-separators) and the as
12 matches
Mail list logo
