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 -0800, Micah Cowan wrote: > To reproduce (in HEAD): > > In a tmux window running the shell, type "seq 1 100", letting the output > scroll the screen (if you've got more than 100 lines on your term, then > give a higher value to seq's second arg). > > ... > 97 > 98 > 99 > 100 > micah$ > > Enter copy-mode, leaving the cursor still at the last line, and scroll > up a line, using Ctrl-Up, K, or C-y. Instead of the prompt scrolling off > the screen, it will remain where it is, and all the lines above it will > scroll: > > ... > 98 > 99 > micah$ > > hit C-y (or whatever) again. You'll see: > > ... > 97 > 98 > 100 > > (Note the missing "99".) In each case, the bottom line is displaying the > line _after_ the proper one, which is not visible. > > > Cause: > > The culprit is in this snippet from window_cursor_copy_up(), in > window-copy.c, which takes effect _after_ the actual scroll (which > writes the proper line): > > if (scroll_only) > window_copy_redraw_lines(wp, data->cy, 2); > > (For me, this is on line 1090.) When data->cy is the last line, > window_copy_redraw_lines will first redraw the final line again, and > then, attempt to "redraw" the next line down. It'll fail to advance the > cursor (since screen_write_cursormove() detects this problem), so just > write the next line over the proper last line. > > While I can see what the problem is, I'm not yet comfortable enough with > the code to be sure of the solution. It's not entirely clear to me why > this redraw happens at all (though the CVS log mentions an end-of-line > marker "$"). It's equally unclear to me whether this should be handled > at the point of call to window_copy_redraw_lines() (to limit the third > argument in the event we're at the end), within > window_copy_redraw_lines() to exit the loop when we're past the last > line, or within window_copy_write_line() to return early when copying > the last line is detected. I suspect the first option is the most > cumbersome, as it could potentially require every caller to first check > and adjust the number of lines; the second option seems reasonable, and > perhaps the third should be done just in case it's missed by a different > caller? The patch I've attached does both of those, in case that's how > you want to go with this. > > -- > Micah J. Cowan > http://micah.cowan.name/ > ------------------------------------------------------------------------------ > Throughout its 18-year history, RSA Conference consistently attracts the > world's best and brightest in the field, creating opportunities for Conference > attendees to learn about information security's most important issues through > interactions with peers, luminaries and emerging and established companies. > http://p.sf.net/sfu/rsaconf-dev2dev > _______________________________________________ > tmux-users mailing list > tmux-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/tmux-users ------------------------------------------------------------------------------ Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev _______________________________________________ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
