>> but tmux doesn't change behavior - pane's lines separator always >> looks like series of xxx or qqq instead of lines.
>Read the FAQ or run CVS HEAD. Do you mean this one? /* * I use PuTTY and my tmux window pane separators are all qqqqqqqqq's! * *PuTTY is using a character set translation that doesn't support ACS line *drawing. With a Unicode font, try setting PuTTY to use a different translation *on the Window -> Translation configuration page. For example, change UTF-8 to *ISO-8859-1 or CP437. It may also be necessary to adjust the way PuTTY treats *line drawing characters in the lower part of the same configuration page. * */ I am pretty sure that this advice is incorrect, because when changing the translation from UTF-8 to some other codepage, the information will get all messed up and become incompatible with the rest of the world. IMHO it is better to see by yourself. I'll create filenames with the same phrase "Hello world" but in different languages and we will see how advice from FAQ above would work: 1. tmux with UTF-8 http://img163.imageshack.us/img163/1921/tmuxutf8langs.jpg Result: as you can see all languages displayed correctly in human readable format, but pane's line separator is out of scope, lines displayed as 'xxxxxxx' 2. tmux with ISO-8859-1 (FAQ advice #1) http://img695.imageshack.us/img695/545/tmuxiso885901langs.jpg Result: All languages that used something other than latin is a garbage, but we got a pane's line separator. 3. tmux with cp437 (FAQ advice #2) http://img19.imageshack.us/img19/6373/tmuxcp437langs.jpg Result: All languages that used something other than latin is a garbage, but we got a pane's line separator. I really don't think that someone would sacrifice ability to use all languages in the world in readable format and in the same time without switching between codepages just to be able to see nice lines drawing. Switching translation to obsolete codepages system - it just loosing the whole point of UTF-8. I know that PuTTY can't handle ACS lines under UTF-8 (and not only PuTTY), and I believe it shouldn't. There is no good reason for applications to use ACS lines if environment support UTF-8 which by itself supports a bunch of standardized nice lines and at the same time it support all languages without switching between codepages. I'm pretty sure that using ISO-2022 under UTF-8 environment - it would be wrong. I'm not the only one who feels this way about this problem : http://www.cl.cam.ac.uk/~mgk25/unicode.html#term http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/utf8-plus-vt100.html So, if environment set to LANG=xx_XX.UTF-8 it's clearly told to all applications to use UTF-8 only and don't mix it with old VT-100 esc-sequences for line drawing. I have a humble feature request because I'd really like tmux and just want it would be more better: Is there any hope to add a config option that would allow override ACS lines to simple one like it does ncurses with NCURSES_NO_UTF8_ACS=1 ? Or just treat that variable in the same way as ncurses. (switch line drawing to characters below 0x7f (poor man graphics with -|+) Another (imho the right way) suggestion: Switch to UTF-8 lines characters when environment is set to UTF-8. In that case there is a way to use a bunch of different, standardized nice lines characters and forget to worry forever about incompatibilities. Anyway UTF-8 has a future, but I couldn't tell the same about ACS of VT-100. ACS can be still useful with old hardware and stupid codepages, but not in UTF-8, there just simply no need in them. I guess everybody can benefit on that. Actually there is another approach to resolve this issue in UTF-8 aware terminals, by replacing 'acsc' in the terminfo('ac' in the termcap) with acsc=a\376k\277l\332m\300j\331n\305w\302v\301u\264t\303q\304x\263h\2600\333 but imho it is a wrong way. Personally, I resolve this issue by setting foreground and background color of pane's borders to the same color: set-option -g pane-border-fg white set-option -g pane-border-bg white set-option -g pane-active-border-fg green set-option -g pane-active-border-bg green In that case ugly "lqqqq" characters sequence is simply hidden. > mc is probably checking for the mouse in some stupid way, maybe by > looking for exactly xterm* and rxvt* or for STY. Does it work in screen? The same with the screen. >Are you sure there is no option to force it to turn on the mouse? mc support -x option #mc --help-terminal >GNU Midnight Commander 4.7.4 > > >Terminal options > -x, --xterm Forces xterm features but unfortunately it doesn't help - no mouse support. Let me figure out with them first this issue. After digging it deeper I conclude they support only xterm or rxvt only.(really don't know - why?) >ncurses has almost nothing to do with tmux, it is only used to read terminfo. That is exactly why I tried reinstall ncurses with terminfo support because by default FreeBSD use termcap, so, I just thought may be tmux need terminfo db. Best regards, Alex. ------------------------------------------------------------------------------ Nokia and AT&T present the 2010 Calling All Innovators-North America contest Create new apps & games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev _______________________________________________ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
