End of word in copy mode; don't include following character.

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 curren

Re: return of the son of reflow from 50,000 fathoms

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 if

Re: return of the son of reflow from 50,000 fathoms

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. >

Re: Simple patch to indicate prefix-status in status line

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 myse

Re: return of the son of reflow from 50,000 fathoms

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 +++ b/g

Re: return of the son of reflow from 50,000 fathoms

I don't think we need this, I think we should start off with previous_wrapped = 0 not 1. Here's latest with that and another fix. diff --git a/grid.c b/grid.c index aabf66c..355e0b3 100644 --- a/grid.c +++ b/grid.c @@ -70,6 +70,11 @@ grid_check_y(struct grid *gd, u_int py) } #endif +void gr

Re: return of the son of reflow from 50,000 fathoms

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 b/gri

Re: return of the son of reflow from 50,000 fathoms

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 *, u_int

Re: return of the son of reflow from 50,000 fathoms

I just made this core so maybe wait for a wee bit first :-). On Sun, Feb 10, 2013 at 02:06:12PM +, Nicholas Marriott wrote: > 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

return of the son of reflow from 50,000 fathoms

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 c