Hi
The current reflow code is nice and simple but as Thomas has discovered
it is pretty slow. Particularly on FreeBSD apparently, my guess would be
because it does a lot of realloc and is hitting some suboptimal case in
their libc.
So the diff below avoids allocation and does memcpy rather than
Here is a working version, at least for the last minute or so :-).
diff --git a/grid.c b/grid.c
index aabf66c..7088b79 100644
--- a/grid.c
+++ b/grid.c
@@ -70,6 +70,10 @@ grid_check_y(struct grid *gd, u_int py)
}
#endif
+void grid_reflow_join(struct grid *, u_int *, struct grid_line *,
On Sun, Feb 10, 2013 at 02:11:32PM +, Nicholas Marriott wrote:
Here is a working version, at least for the last minute or so :-).
Here's a tiny fixup which was causing xrealloc to complain of there being
nothing to realloc (zero size) when trying to split a window:
diff --git a/grid.c
And another version. previous_wrap had to be 1 at the start to eat the
blank line inserted because py started at 0 and was incremented before
use. So switch things around so the line is incremented after it is
used.
diff --git a/grid.c b/grid.c
index aabf66c..3bf02ae 100644
--- a/grid.c
+++
I'm made status-* use formats and add client_prefix format so you can do
eg #{?client_prefix,X,Y}.
On Sat, Jan 19, 2013 at 11:35:15PM +, Daniel wrote:
But I'm not sure about the indicator - why did you choose ^ and _? It
seems ugly.
I was just looking for this little feature myself.
Thanks.
On Sun, Feb 10, 2013 at 03:20:20PM -0500, Richard Woodbury wrote:
I worried that my code did a lot of reallocations, but it ran fine even on
my older machines, so I let it be. This was also less of a concern when it
was an optional feature, but now it matters greatly.
I worried that my code did a lot of reallocations, but it ran fine even on
my older machines, so I let it be. This was also less of a concern when it
was an optional feature, but now it matters greatly.
Nicholas, your latest patch passes my smoke test. I will continue to use it
and let you know
I have noticed an inconsistency among tmux copy mode and vim. In
particular,
the 'e' key behaves slightly differently.
Here are the behaviors of 'e' that I have observed:
* tmux copy mode: repositions cursor to end of current word + 1.
* vim:repositions cursor to end of
