On Wed, May 18, 2011 at 01:53:05PM -0700, Micah Cowan wrote: > (05/18/2011 01:47 PM), Robin Lee Powell wrote: > > On Wed, May 18, 2011 at 01:43:38PM -0700, Micah Cowan wrote: > >> (05/18/2011 01:28 PM), Micah Cowan wrote: > >>> (05/18/2011 01:19 AM), Robin Lee Powell wrote: > >>>> It's vim, not less, and yes, it appears to be overwriting. > >>>> > >>>> The issue is that I don't have this problem in screen. > >>>> > >>>> OK, screenshots of screen and tmux (in alternate-screen off mode). > >>>> Process is: > >>>> > >>>> [new window] > >>>> # seq 1 100 > >>>> # vim > >>>> [type some crap] > >>>> :q! > >>>> [backscroll mode, up 10 lines, screenshot] > >>> > >>> To be absolutely clear, by "backscroll mode", you mean tmux's > >>> copy-mode, right? It's not some scrollback that's built into the > >>> terminal, is it? > >> > >> See, here's the thing: I can't reproduce your symptoms, even by > >> catting your tmux.txt and tmux2.txt directly into my tmux session > >> (with hopefully approximately the same dimensions - I'm using > >> 195x73 (72 within tmux - not that it should really matter)). Every > >> time, when I enter copy-mode, I can see the "150" from seq after > >> exiting tmux. > > > > Yeah, I thought we had already established that you couldn't repro. > > Catting it out has the same problems for me. > > Well, we had already established that I couldn't repro via the same > _steps_ as you. But now we've established that I couldn't even repro > with the same exact terminal codes that were sent to tmux, which is > rather different.
Yes, you're right of course, sorry. Not that I *do* get the same behaviour with cat of those files, *if* the terminal is exactly the same size. I've created new files in 80x25 for you to test with; see below. > There's plenty of ways that we could get different results from > the same steps, but there aren't many ways we could get different > results from the same escape sequences. Assuming that the problem > is that the scrollback is being overwritten (the other possibility > would be that it's not being drawn properly when you go to > copy-mode, but this seems less likely), the only real explanation > I can think of is that there's a crucial difference between the > way our tmuxen behave, yours and mine. I've now grabbed :pserver:anonym...@tmux.cvs.sourceforge.net:/cvsroot/tmux and am running that binary directly. The behaviour is now slightly different: I can still repro the behaviour by doing it again from scratch, but when I cat tmux2.txt, I can see the 150 (whereas before I don't think I could?). As part of this I also switched computers (availability of compilation tools), so to avoid confusion, re-doing scripts. tmux.conf is only set-option -g prefix C-t set-window-option -g alternate-screen off screenrc is only escape ^Tt defbce "on" It turns out that the latter is required, at least on this machine (but apparently not on the other one I was testing on) for screen to behave the way I want. Without it I get exactly the same overwrite behaviour as tmux. I can provide a script of screen doing the wrong thing if it'll help. No tmux running at all anywhere on the box. Terminal size is 80x25, because I believe that to actually be relevant to the behaviour one gets on catting them back out. Launch screen/tmux, export PS1='$ ' ; export SHELL='/bin/sh' , script, seq, vim. http://teddyb.org/~rlpowell/media/public/tmp/screen_new_1.txt http://teddyb.org/~rlpowell/media/public/tmp/tmux_new_1.txt Note that at this point the *only* things in common are my vimrc (which I've already tried removing for testing purposes; didn't help), possible some /bin/sh profile stuff?, PuTTY, and the machine I'm running putty from (Window 7 box). 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. Now, same thing, but script before screen/tmux, and two pages of backscroll up after the vim, the exit backscroll, then quit: http://teddyb.org/~rlpowell/media/public/tmp/screen_script_new_1.txt http://teddyb.org/~rlpowell/media/public/tmp/tmux_script_new_1.txt Under screen (with zsh), catting screen_new_1.txt gives me 150 in backscroll; catting tmux_new_1.txt gives me only 128 in backscroll. 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. If I make the terminal slightly smaller (70x20), then I get a few more lines in screen and tmux both when catting tmux_new_1.txt (132 and 133, resp, iirc). > 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? > It's possible that the setting of TERM (set by Putty) could effect > that in some way (what's it set to, xterm?), but beyond that... I don't actually see such a setting; "answerback to ^E" is set to PuTTY; not sure ef that's relevant. Ah. terminal type string is set to xterm. -Robin -- http://singinst.org/ : Our last, best hope for a fantastic future. Lojban (http://www.lojban.org/): The language in which "this parrot is dead" is "ti poi spitaki cu morsi", but "this sentence is false" is "na nei". My personal page: http://www.digitalkingdom.org/rlp/ ------------------------------------------------------------------------------ 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
