Hi guys,

Quickly glazing through the thread, a couple of remarks:

- screen/tmux indeed needs that TERM inside them is something
screen-related. Forget xterm or xterm-256color, go with screen,
screen-256color or screen.xterm-256color or alike. This is properly
documented in their docs/faqs and answered on hundreds of random forums
(whereas, of course, the opposite is also answered on random forums, you
should use common sense which answers to trust :)) The most notable
difference is the lack of "bce" causing colored lines (e.g. in midnight
commander) not to fill the entire line, but there are other differences as
well.

- The most standard setup according to my experiences is that TERM=xterm of
the graphical terminal emulator (8/16 colors) translates into TERM=screen
inside (also 8/16 colors), whereas TERM=xterm-256color of the external
emulator ideally translates into TERM=screen-256color. I haven't heard of
any problems with this approach. (Well, strictly speaking you're still in
trouble if you launch screen from a 256-color emulator, detach and then
re-attach from an 8/16-color one.)

- Then ncurses added screen.xterm-256color, which, according to screen's
old-time behavior of prepending "screen." if such a definition is
available, messed up ssh'ing and friends. Of course given screen's
behavior, there's no way such a change could've been introduced without
such breakages.

- I don't understand why you're reluctant moving screen.xterm and
screen.xterm-256color from ncurses-term into ncurses-base. Of course it
wouldn't fix a thing now, but it's not clear to me what it'd break, and
it's desired to make screen.xterm{,-256color} widely available in the long
run. Please do it as soon as possible.

- On my machine (Ubuntu Artful) screen-256color and screen.xterm-256color
are not exactly the same file. We should investigate what's the difference
and why, and which one's the better to have.

- 256 colors became pretty standard perhaps like 5-7 years ago. Since then,
some of us put noticeable effort into pushing even further and have
truecolor support here and there (with less limited success than 256
colors, but it's already available at many places). Please, pretty please
don't make a step backwards and don't advocate solutions/workaround that
reduce the available colors to 8/16. Please don't recommend TERM=xterm or
TERM=screen as a workaround where the underlying terminal is known to
support 256 colors.

- A proper workaround might be to set screen-256color from screenrc, or
translate TERM=screen.xterm-256color into TERM=screen-256color in
/etc/bashrc.

- I've never seen anyone quoting from me; Sven, I'm happy to see you did :)
I can't remember where I wrote those exact words, but I've sure written
something analogous at multiple places. One day I might write a standalone
page summarizing all the issues and outlining a recommendation for
something better.

cheers,
egmon

Reply via email to