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 n
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, Ma
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 Neukirchenhtt
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 direc
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 wo
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:
