tmux - lost lines
Hi, when I cat big file, some lines of file are lost i=1 while [ $i -le 500 ] do echo "line number: $i line number: $i line number: $i" i=`expr $i + 1` done this script works fine none of lines are lost but if you save output in file and cut this file line number: 62 line number: 62 line number: 62 line number: 63 line number: 63 line number: 63 line number: 64 line number: 64 line number: 64 line number: 162 line number: 162 line number: 162 line number: 163 line number: 163 line number: 163 line number: 164 line number: 164 line number: 164 line number: 284 line number: 284 line number: 284 line number: 285 line number: 285 line number: 285 line number: 286 line number: 286 line number: 286 line number: 395 line number: 395 line number: 395 line number: 396 line number: 396 line number: 396 line number: 397 line number: 397 line number: 397 cat is much faster then this script and tmux can't keep up, IMHO some buffers overflow and lines are lost please fix if it possible it's too disapointed thanks -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb___ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
Re: bug with mode-mouse on
I use the latest iTerm2 and I checked in the preferences to find anything about UTF-8, and the only thing I found was "Character Encoding: Unicode (UTF-8)". I tried turning the option mouse-utf8 off and on, but that didn't make any difference. It does happen with uxterm too. Actually, it seems worse in uxterm; the problem happens in a larger fraction of the window. It seems that what matters is not the physical width of the window, but how many characters it spans horizontally. I tried this: With normal font size, I click near the right end of the window and it spits garbage. Then I make the fonts bigger (Ctrl-+). The window is enlarged initially. I click on the right end of the window, and it spits garbage again. BUT, if I shrink the window back to its previous size, so as to contain fewer characters than before (since the characters now are bigger but the window size is made the same as before), then I can click without getting garbage. The font in uxterm is much smaller than in my iterm. So, that's probably why the problem is worse in uxterm. If, let's assume, the problem starts on the 80th character, then in uxterm the 80th character occurs sooner, i.e., a bigger part of my window is problematic. Thank you! On Sun, Mar 3, 2013 at 6:39 PM, Nicholas Marriott < nicholas.marri...@gmail.com> wrote: > Are you sure your terminal supports UTF-8 mouse sequences? Does this > happen in uxterm too? > > > On Thu, Feb 28, 2013 at 03:34:44PM -0500, Georgios Choudalakis wrote: > >Hi all, > >I have these options: > >* * * * * * * * * * * * * * * * * * * * * * * > ># scroll with my mouse in history mode. * * * > >set-window-option -g mouse-select-window on * > >set-window-option -g mouse-select-pane on * * > >set-window-option -g mouse-resize-pane on * * > >set-window-option -g mouse-utf8 on * * * * ** > >set-window-option -g mode-mouse on * * * * ** > >I run iTerm2 on Mac OS X 10.7.5. with a 24-inch screen. > >The problem is that when I increase the width of my window to span > most of > >my screen's width, then mouse clicks on the right end of the window > are > >interpreted incorrectly. *They generate garbage, which looks as if a > >monkey was hitting the keyboard: * "@ 23 *M oig dfgoij *ds##g"* > >and other such meaningless keystrokes. > >Mouse clicks on the rest of my window work fine, and they result in > pane > >selection or in pane resizing, etc. *The problem only occurs if the > window > >is big enough, and I click near the right of the window, to select for > >example the rightmost pane. * The problem persists regardless of the > >absolute position of my window, and even if I move it to a secondary > >monitor that I have connected. > >I would greatly appreciate fixing this bug, if possible. > >I already have to say I LOVE tmux, and you are making the world a > better > >place. * > >Thank you! > > > > -- > > Everyone hates slow websites. So do we. > > Make your web apps faster with AppDynamics > > Download AppDynamics Lite for free today: > > http://p.sf.net/sfu/appdyn_d2d_feb > > > ___ > > tmux-users mailing list > > tmux-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/tmux-users > > -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb___ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
Re: bug with mode-mouse on
Hmm. Without UTF-8, the maximum width is about 200 or so IIRC, with UTF-8 it should be larger. Please run: tmux -uLtest -v new\; set -g mouse-select-pane on\; splitw And click a few times to reproduce the problem and then exit tmux and send me the tmux-server*.log file from the current directory. On Mon, Mar 04, 2013 at 09:58:14AM -0500, Georgios Choudalakis wrote: >I use the latest iTerm2 and I checked in the preferences to find anything >about UTF-8, and the only thing I found was "Character Encoding: Unicode >(UTF-8)". >I tried turning the option mouse-utf8 off and on, but that didn't make any >difference. >It does happen with uxterm too. *Actually, it seems worse in uxterm; the >problem happens in a larger fraction of the window. >It seems that what matters is not the physical width of the window, but >how many characters it spans horizontally. *I tried this: *With normal >font size, I click near the right end of the window and it spits garbage. >*Then I make the fonts bigger (Ctrl-+). *The window is enlarged initially. >*I click on the right end of the window, and it spits garbage again. *BUT, >if I shrink the window back to its previous size, so as to contain fewer >characters than before (since the characters now are bigger but the window >size is made the same as before), then I can click without getting >garbage. >The font in uxterm is much smaller than in my iterm. *So, that's probably >why the problem is worse in uxterm. *If, let's assume, the problem starts >on the 80th character, then in uxterm the 80th character occurs sooner, >i.e., a bigger part of my window is problematic. >Thank you! > >On Sun, Mar 3, 2013 at 6:39 PM, Nicholas Marriott ><[1]nicholas.marri...@gmail.com> wrote: > > Are you sure your terminal supports UTF-8 mouse sequences? Does this > happen in uxterm too? > > On Thu, Feb 28, 2013 at 03:34:44PM -0500, Georgios Choudalakis wrote: > > * *Hi all, > > * *I have these options: > > * ** * * * * * * * * * * * * * * * * * * * * * * > > * *# scroll with my mouse in history mode. * * * > > * *set-window-option -g mouse-select-window on * > > * *set-window-option -g mouse-select-pane on * * > > * *set-window-option -g mouse-resize-pane on * * > > * *set-window-option -g mouse-utf8 on * * * * ** > > * *set-window-option -g mode-mouse on * * * * ** > > * *I run iTerm2 on Mac OS X 10.7.5. with a 24-inch screen. > > * *The problem is that when I increase the width of my window to span > most of > > * *my screen's width, then mouse clicks on the right end of the window > are > > * *interpreted incorrectly. *They generate garbage, which looks as if > a > > * *monkey was hitting the keyboard: * "@ 23 *M oig dfgoij *ds##g"* > > * *and other such meaningless keystrokes. > > * *Mouse clicks on the rest of my window work fine, and they result in > pane > > * *selection or in pane resizing, etc. *The problem only occurs if the > window > > * *is big enough, and I click near the right of the window, to select > for > > * *example the rightmost pane. * The problem persists regardless of > the > > * *absolute position of my window, and even if I move it to a > secondary > > * *monitor that I have connected. > > * *I would greatly appreciate fixing this bug, if possible. > > * *I already have to say I LOVE tmux, and you are making the world a > better > > * *place. * > > * *Thank you! > > > > > -- > > Everyone hates slow websites. So do we. > > Make your web apps faster with AppDynamics > > Download AppDynamics Lite for free today: > > [2]http://p.sf.net/sfu/appdyn_d2d_feb > > > ___ > > tmux-users mailing list > > [3]tmux-users@lists.sourceforge.net > > [4]https://lists.sourceforge.net/lists/listinfo/tmux-users > > References > >Visible links >1. mailto:nicholas.marri...@gmail.com >2. http://p.sf.net/sfu/appdyn_d2d_feb >3. mailto:tmux-users@lists.sourceforge.net >4. https://lists.sourceforge.net/lists/listinfo/tmux-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
Re: tmux - lost lines
Irakli writes: > Hi, > when I cat big file, some lines of file are lost > cat is much faster then this script and tmux can't keep up, > IMHO some buffers overflow and lines are lost > please fix if it possible it's too disapointed Try setw -g c0-change-trigger 0 -- Christian Neukirchenhttp://chneukirchen.org -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
Re: bug with mode-mouse on
tmux is correctly seeing this as mouse input and well above 80 columns. Are you sure these are being forwarded to the shell in the pane? Can you do the same, but this time only click once at the right-hand edge and tell me what you see appear in the pane as well as sending the logs? On Mon, Mar 04, 2013 at 10:18:24AM -0500, Georgios Choudalakis wrote: >Done. *Here are the logs. >Thanks! > >On Mon, Mar 4, 2013 at 10:11 AM, Nicholas Marriott ><[1]nicholas.marri...@gmail.com> wrote: > > Hmm. Without UTF-8, the maximum width is about 200 or so IIRC, with > UTF-8 it should be larger. > > Please run: > > tmux -uLtest -v new\; set -g mouse-select-pane on\; splitw > > And click a few times to reproduce the problem and then exit tmux and > send me the tmux-server*.log file from the current directory. > > On Mon, Mar 04, 2013 at 09:58:14AM -0500, Georgios Choudalakis wrote: > > * *I use the latest iTerm2 and I checked in the preferences to find > anything > > * *about UTF-8, and the only thing I found was "Character Encoding: > Unicode > > * *(UTF-8)". > > * *I tried turning the option mouse-utf8 off and on, but that didn't > make any > > * *difference. > > * *It does happen with uxterm too. *Actually, it seems worse in > uxterm; the > > * *problem happens in a larger fraction of the window. > > * *It seems that what matters is not the physical width of the window, > but > > * *how many characters it spans horizontally. *I tried this: *With > normal > > * *font size, I click near the right end of the window and it spits > garbage. > > * **Then I make the fonts bigger (Ctrl-+). *The window is enlarged > initially. > > * **I click on the right end of the window, and it spits garbage > again. *BUT, > > * *if I shrink the window back to its previous size, so as to contain > fewer > > * *characters than before (since the characters now are bigger but the > window > > * *size is made the same as before), then I can click without getting > > * *garbage. > > * *The font in uxterm is much smaller than in my iterm. *So, that's > probably > > * *why the problem is worse in uxterm. *If, let's assume, the problem > starts > > * *on the 80th character, then in uxterm the 80th character occurs > sooner, > > * *i.e., a bigger part of my window is problematic. > > * *Thank you! > > > > * *On Sun, Mar 3, 2013 at 6:39 PM, Nicholas Marriott > > * *<[1][2]nicholas.marri...@gmail.com> wrote: > > > > * * *Are you sure your terminal supports UTF-8 mouse sequences? Does > this > > * * *happen in uxterm too? > > > > * * *On Thu, Feb 28, 2013 at 03:34:44PM -0500, Georgios Choudalakis > wrote: > > * * *> * *Hi all, > > * * *> * *I have these options: > > * * *> * ** * * * * * * * * * * * * * * * * * * * * * * > > * * *> * *# scroll with my mouse in history mode. * * * > > * * *> * *set-window-option -g mouse-select-window on * > > * * *> * *set-window-option -g mouse-select-pane on * * > > * * *> * *set-window-option -g mouse-resize-pane on * * > > * * *> * *set-window-option -g mouse-utf8 on * * * * ** > > * * *> * *set-window-option -g mode-mouse on * * * * ** > > * * *> * *I run iTerm2 on Mac OS X 10.7.5. with a 24-inch screen. > > * * *> * *The problem is that when I increase the width of my window > to span > > * * *most of > > * * *> * *my screen's width, then mouse clicks on the right end of the > window > > * * *are > > * * *> * *interpreted incorrectly. *They generate garbage, which looks > as if > > * * *a > > * * *> * *monkey was hitting the keyboard: * "@ 23 *M oig dfgoij > *ds##g"* > > * * *> * *and other such meaningless keystrokes. > > * * *> * *Mouse clicks on the rest of my window work fine, and they > result in > > * * *pane > > * * *> * *selection or in pane resizing, etc. *The problem only occurs > if the > > * * *window > > * * *> * *is big enough, and I click near the right of the window, to > select > > * * *for > > * * *> * *example the rightmost pane. * The problem persists > regardless of > > * * *the > > * * *> * *absolute position of my window, and even if I move it to a > > * * *secondary > > * * *> * *monitor that I have connected. > > * * *> * *I would greatly appreciate fixing this bug, if possible. > > * * *> * *I already have to say I LOVE tmux, and you are making the > world a > > * * *better > > * * *> * *place. * > > * * *> * *Thank you! > > > > * * *> > > * * > > *-- > > * * *> Everyone hates slow websites. So
Re: bug with mode-mouse on
This looks like a problem with your terminal. It is sending ^[[M ^V6 which is not a valid position - the ^V is ASCII 22 which is too low, mouse positions without UTF-8 need to start at ASCII 33. Still, UTF-8 mouse mode should fix this. Can you try the same but this time do: tmux -uLtest -v new\; set -g utf8-mouse on\; set -g mouse-select-pane on\; splitw And send me the logs again. Alternatively if your terminal is new enough SGR mouse mode may fix this. You could try building tmux from git and see if it helps. On Mon, Mar 04, 2013 at 10:50:53AM -0500, Georgios Choudalakis wrote: >Sure, I did it again, this time I clicked only once. >Initially the lower pane was selected. >I clicked on the right side of the screen, within the upper pane. >Instead of moving focus to the upper pane, I heard a beep, and the >following text appeared on the lower prompt: " 6#6" *(without the quotes). >Here are the logs. >Thanks! > >On Mon, Mar 4, 2013 at 10:30 AM, Nicholas Marriott ><[1]nicholas.marri...@gmail.com> wrote: > > tmux is correctly seeing this as mouse input and well above 80 > columns. Are you sure these are being forwarded to the shell in the > pane? > > Can you do the same, but this time only click once at the right-hand > edge and tell me what you see appear in the pane as well as sending the > logs? > > On Mon, Mar 04, 2013 at 10:18:24AM -0500, Georgios Choudalakis wrote: > > * *Done. *Here are the logs. > > * *Thanks! > > > > * *On Mon, Mar 4, 2013 at 10:11 AM, Nicholas Marriott > > * *<[1][2]nicholas.marri...@gmail.com> wrote: > > > > * * *Hmm. Without UTF-8, the maximum width is about 200 or so IIRC, > with > > * * *UTF-8 it should be larger. > > > > * * *Please run: > > > > * * *tmux -uLtest -v new\; set -g mouse-select-pane on\; splitw > > > > * * *And click a few times to reproduce the problem and then exit tmux > and > > * * *send me the tmux-server*.log file from the current directory. > > > > * * *On Mon, Mar 04, 2013 at 09:58:14AM -0500, Georgios Choudalakis > wrote: > > * * *> * *I use the latest iTerm2 and I checked in the preferences to > find > > * * *anything > > * * *> * *about UTF-8, and the only thing I found was "Character > Encoding: > > * * *Unicode > > * * *> * *(UTF-8)". > > * * *> * *I tried turning the option mouse-utf8 off and on, but that > didn't > > * * *make any > > * * *> * *difference. > > * * *> * *It does happen with uxterm too. *Actually, it seems worse in > > * * *uxterm; the > > * * *> * *problem happens in a larger fraction of the window. > > * * *> * *It seems that what matters is not the physical width of the > window, > > * * *but > > * * *> * *how many characters it spans horizontally. *I tried this: > *With > > * * *normal > > * * *> * *font size, I click near the right end of the window and it > spits > > * * *garbage. > > * * *> * **Then I make the fonts bigger (Ctrl-+). *The window is > enlarged > > * * *initially. > > * * *> * **I click on the right end of the window, and it spits > garbage > > * * *again. *BUT, > > * * *> * *if I shrink the window back to its previous size, so as to > contain > > * * *fewer > > * * *> * *characters than before (since the characters now are bigger > but the > > * * *window > > * * *> * *size is made the same as before), then I can click without > getting > > * * *> * *garbage. > > * * *> * *The font in uxterm is much smaller than in my iterm. *So, > that's > > * * *probably > > * * *> * *why the problem is worse in uxterm. *If, let's assume, the > problem > > * * *starts > > * * *> * *on the 80th character, then in uxterm the 80th character > occurs > > * * *sooner, > > * * *> * *i.e., a bigger part of my window is problematic. > > * * *> * *Thank you! > > * * *> > > * * *> * *On Sun, Mar 3, 2013 at 6:39 PM, Nicholas Marriott > > * * *> * *<[1][2][3]nicholas.marri...@gmail.com> wrote: > > * * *> > > * * *> * * *Are you sure your terminal supports UTF-8 mouse sequences? > Does > > * * *this > > * * *> * * *happen in uxterm too? > > * * *> > > * * *> * * *On Thu, Feb 28, 2013 at 03:34:44PM -0500, Georgios > Choudalakis > > * * *wrote: > > * * *> * * *> * *Hi all, > > * * *> * * *> * *I have these options: > > * * *> * * *> * ** * * * * * * * * * * * * * * * * * * * * * * > > * * *> * * *> * *# scroll with my mouse in history mode. * * * > > * * *> * * *> * *set-window-option -g mouse-select-window on * > > * * *> * * *> * *set-window-option -g mouse-select-pane on * * > > * * *> * * *> * *set-window-option -g mo
