FS#26525 - [initscripts] broken display in ncurses, pacman

Attached to Project: Arch Linux
Opened by Link Mauve (linkmauve) - Wednesday, 19 October 2011, 16:42 GMT
Last edited by Tom Gundersen (tomegun) - Wednesday, 09 November 2011, 00:56 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Tom Gundersen (tomegun)
Architecture i686
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 8
Private No

Details

Description:
Since yesterday, every ncurses programs, pacman, and probably other console programs have their display broken in tmux.


Additional info:
* package version(s)
tmux 1.5-1
ncurses 5.9-1
[testing] enabled.


Steps to reproduce:
- launch tmux;
- launch any ncurses program in it, mutt, poezio, ncmpcpp, etc.;
- admire the visual glitches.
This task depends upon

Closed by  Tom Gundersen (tomegun)
Wednesday, 09 November 2011, 00:56 GMT
Reason for closing:  Fixed
Additional comments about closing:  This is fixed in the newest initscripts in [testing].
Comment by Alexander F. Rødseth (xyproto) - Wednesday, 19 October 2011, 21:15 GMT
Works great with htop, despotify, vim, robotfindskitten, iotop, powertop, aafire -driver curses, mc, elinks and ncmpc here.
Which terminal emulator do you use? I use lxterminal on x86_64.

community/lxterminal 0.1.11-1
community/tmux 1.5-1
core/ncurses 5.9-1
Comment by Link Mauve (linkmauve) - Wednesday, 19 October 2011, 21:20 GMT
I mainly use fbterm (1.7.0-4) but I use the Linux TTY (3.0.6-2) and rxvt-unicode (9.12-1) too, and they all do the same.

It seems to be related to UTF-8 handling, because when I launch tmux with LANG=C it works.
Comment by Alexander F. Rødseth (xyproto) - Wednesday, 19 October 2011, 21:44 GMT
Works with urxvt here. What is your output if you type "locale"?
Comment by Link Mauve (linkmauve) - Wednesday, 19 October 2011, 22:57 GMT
I get that, correctly generated, works fine everywhere else:
% locale
LANG=fr_FR.UTF-8
LC_CTYPE=
LC_NUMERIC=
LC_TIME=
LC_COLLATE=
LC_MONETARY="fr_FR.UTF-8"
LC_MESSAGES=
LC_PAPER="fr_FR.UTF-8"
LC_NAME="fr_FR.UTF-8"
LC_ADDRESS="fr_FR.UTF-8"
LC_TELEPHONE="fr_FR.UTF-8"
LC_MEASUREMENT="fr_FR.UTF-8"
LC_IDENTIFICATION="fr_FR.UTF-8"
LC_ALL=
Comment by Mathieu Pasquet (mathieui) - Wednesday, 19 October 2011, 23:21 GMT
Same problem as Link Mauve here (same conditions, same locales).
The problem seems to be with the size tmux attributes to each character. C-l gets it mostly right, but switching windows triggers some of the issues.

Attachments:
- wrongsize.png: I typed "éééééééééééééééééééééééééééé" and then…
- after.png: the output was like in wrongsize.png, but then I went to the previous window and switched again to the next window
- vimchaos.png: basically, the accentuated characters in the left buffer take too much space when switching panes, causing the broken display (C-l puts it back nicely until I switch windows again).
Comment by Alexander F. Rødseth (xyproto) - Thursday, 20 October 2011, 11:40 GMT
Great, I say the bug is nailed. I'll report it to the tmux people upstream. Thanks.

Edit: reported
Comment by Mathieu Pasquet (mathieui) - Thursday, 20 October 2011, 11:53 GMT
The strangest thing is that there hasn't been an tmux update for ages (or anything related to it)…
Comment by Alexander F. Rødseth (xyproto) - Thursday, 20 October 2011, 12:14 GMT
In the mean time, is it a usable workaround to start tmux with "LC_ALL=C tmux"?
Comment by Mathieu Pasquet (mathieui) - Thursday, 20 October 2011, 12:26 GMT
Well, all the unicode-specific (like éècà etc…) characters become "_", but yeah, the display is no longer broken
Comment by Alexander F. Rødseth (xyproto) - Monday, 24 October 2011, 09:21 GMT
I sent an e-mail to the tmux developers and got a reply from Nicholas Marriott.
LC_ALL and/or LC_CTYPE should not be set to empty (''), but to a UTF-8 locale, or unset completely.

Does it work for you if you make sure both LC_ALL and LC_CTYPE are set?
Comment by Simon Jacquin (Minos) - Monday, 24 October 2011, 11:28 GMT
Same problem here. I does work if I set LC_ALL and LC_CTYPE.
Comment by Dave Reisner (falconindy) - Monday, 24 October 2011, 12:29 GMT
Does this work with another UTF-8 locale like en_US.UTF-8? Can you regenerate your fr_FR locale? This seems more likely to be a specific issue with fr_FR than with tmux.

It's extremely fishy that LC_MESSAGES and the like aren't filled in your `locale' output. However, it should be noted that LC_ALL should _never_ be set. It's meant for debugging as a temporary override -- not for normal usage.
Comment by Christoph Kappel (unexist) - Monday, 24 October 2011, 16:14 GMT
Happens for me with ncmpcpp, when I set LC_CTYPE before I start tmux the problem is gone.
Comment by Dave Reisner (falconindy) - Monday, 24 October 2011, 16:50 GMT
This has nothing to do with tmux or ncurses.

This is a ZSH issue with the new locale.sh. Unlike bash, ZSH will export an unset variable (with no value).

$ export FOO
$ declare -p FOO
-bash: declare: FOO: not found

% export FOO
% declare -p FOO
typeset -x FOO=''
Comment by Dave Reisner (falconindy) - Monday, 24 October 2011, 16:50 GMT
Updated title and assignees.
Comment by Tom Gundersen (tomegun) - Monday, 24 October 2011, 19:52 GMT
Sorry about this guys, my bad.

Could you check if replacing /etc/profile.d/locale.sh with this: <https://raw.github.com/teg/initscripts-arch/master/locale.sh> fixes the problem?
Comment by Patrick Palka (orlandu63) - Tuesday, 25 October 2011, 04:18 GMT
The replacement locale.sh fixes the visual glitches for me.
Comment by Erik Johnson (archtaku) - Tuesday, 25 October 2011, 04:41 GMT
The replacement locale.sh is working for me as well.
Comment by Tom Gundersen (tomegun) - Tuesday, 25 October 2011, 06:56 GMT
Thanks guys, I'll include it in the next initsrcipts release (after some more testing :) ).
Comment by CuleX (CuleX) - Saturday, 05 November 2011, 09:02 GMT
From https://raw.github.com/teg/initscripts-arch/master/locale.sh:
------
if [ -n "$LC_TELEPHONE" ]; then
export LC_MEASUREMENT
else
unset LC_MEASUREMENT
fi
------
I'm not a locale expert, but are you sure that's correct?
Comment by Tom Gundersen (tomegun) - Saturday, 05 November 2011, 23:41 GMT
To the contrary, I'm sure it is incorrect ;-) Thanks for the headsup, fixed in git.

Loading...