= Background =
I've noticed that the "next-word" copy-mode command, bound to "M-f" in
emacs-mode and to "w" in vi-mode, behaves more like vi's "e", which
skips to the next word-ending, than its "w", which skips to the next
word-beginning.
Also, the vi copy mode currently lacks vi's uppercased equ
On Sun, Jan 24, 2010 at 11:35:34AM -0800, Micah Cowan wrote:
> Nicholas Marriott wrote:
> > Ugh, another copy mode bug.
> >
> > Thanks for your diff.
> >
> > We need to redraw two lines because if the $ is at the end of the line it
> > will
> > have been scrolled.
> >
> > I think it is enough j
Nicholas Marriott wrote:
> Ugh, another copy mode bug.
>
> Thanks for your diff.
>
> We need to redraw two lines because if the $ is at the end of the line it will
> have been scrolled.
>
> I think it is enough just to change window_copy_write_line, although I'll move
> the check up a bit I thin
I'm not sure we need to document them both, anyone who wants them will try them
and find out quickly enough. I think the key bindings should follow vi as far
as possible (unless there is a good reason not to) and that's what we should
mention, the others are just conveniences because they don't hap
Okay, the basic problem was laziness.
Please try this.
Previously, new and attach were errors from inside tmux but that has now been
fixed so even eg "tmux new\; new\; new\; attach -t1" should work.
Index: cmd-list.c
===
RCS file:
Ugh, another copy mode bug.
Thanks for your diff.
We need to redraw two lines because if the $ is at the end of the line it will
have been scrolled.
I think it is enough just to change window_copy_write_line, although I'll move
the check up a bit I think.
On Sat, Jan 23, 2010 at 11:14:24PM -08
I like this, but I want to have a look at the code and figure out why it ends
it. It would be nice to fix this nonobvious behaviour if possible, rather than
documenting it.
The entire command is sent up from the client to the server and broken up
there, so I can't offhand think of a reason it shou
