(05/18/2011 02:56 PM), Robin Lee Powell wrote: > Terminal size is 80x25, because I believe that to actually be > relevant to the behaviour one gets on catting them back out.
Well, what I meant (and should have said) was, provided that the lines all start where they're meant to. > http://teddyb.org/~rlpowell/media/public/tmp/tmux_new_1.txt There is definitely some different behavior of vim under tmux here. And the reason it's still happening is that, before, vim was issuing "clear screen", which in many terminals actually just scrolls a full page rather than truly erasing. It looks like previous versions of tmux would actually erase the screen, rather than scroll a page-size, which was the source of your trouble there (Note that was still completely legitimate behavior, but I'm definitely happier with the current behavior). However, according to tmux_new_1.txt, vim is no longer issuing the "clear screen" code; it just jumps to column 1 and starts drawing. That's guaranteed to overwrite history (except when alternate-screen is _on_, in which case it'd get restored back on exit - but then it would overwrite the "remains" that you like to have). A workaround should be to alias vim to 'clear; vim' or something. What I don't understand is: what made vim change what it's sending in terminal codes? TERM was set to screen in both cases, right? ...or do you have TERM set inappropriately within tmux? And why isn't it doing the exact same thing when you're running it under screen? It looks like vim _is_ still sending the clear-screen codes in screen_new_1.txt (which is why it's still working)... what's different? I suspect you changed something relative to how you were running it in tmux2.txt; something made it stop clearing the screen. > Fascinatingly, I just discovered by accident that if I run screen > with tmux underneath it, and use screen's backscroll, I still can't > see the lines that vim overwrites. No surprise there. Tmux doesn't try to preserve the host terminal's scrollback as far as I know. > Under tmux (with zsh), *this is also true*: catting screen_new_1.txt > gives me 150 inbackscroll; catting tmux_new_1.txt gives me only 128 > in backscroll. Yeah, this makes sense given my explanation above. The key question is, what's different inside the screen/tmux terminal that is causing clear not to be sent. >> You mentioned not changing Putty, but I can't think of a good >> reason that Putty would be directly involved. Particularly since >> your latest script demonstrates that tmux is definitely even >> sending the codes to draw the appropriate bit of the scrollback. > > Wait, what? tmux_script.txt shows that tmux is *not* showing all > the way down to 150? Um, right. Just like you said it wasn't? It shows all the way down to 150, and does some vimmy stuff, and then when you do a scrollback, it only draws it down to like 129. But this is all done at once of course, since you don't have timing info. -- Micah J. Cowan http://micah.cowan.name/ ------------------------------------------------------------------------------ What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
