The advice is fine. If you don't use tmux CVS HEAD, it is a choice you as the user has to make - either you want UTF-8 or you want nice line drawing characters. This is the choice putty forces on you with their disdain for backwards compatibility.
Saying that every application should use UTF-8 line drawing characters is bullshit. It forces UTF-8 (which is often hard to add and unnecessary) onto all existing programs - and what if the project is no longer maintained? (Like putty!) Note that sometimes vt100 characters are BETTER than UTF-8, which don't always line up properly. vt100 has been around for longer than UTF-8, putty should be a vt100 emulator FIRST and support UTF-8 SECOND. Like everyone else. There is NO reason not to support both ACS and UTF-8 line drawing characters together. Saying it is a standard is not an excuse. There are so many standards, choose another one! This standard was written by UTF-8 fanboys, not by people who understand Unix terminal emulators. xterm is the de facto standard terminal emulator, follow what it does. Or skip the bits that are stupid and add a "pedantic" option. Or you can use CVS HEAD where tmux supports UTF-8 line drawing characters. Or fixing it with terminfo is fine, which is fine - that's why it supports .terminfo. On Mon, Nov 01, 2010 at 10:59:26PM -0700, JoAT, Inc. wrote: > >> 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
