[question] Should not we enable xterm-256color on mintty by default?

[luau-project]

Description

Note

Since I am relatively new to terminal-related topics, I opened this issue to read opinions from people with more experience on this subject, because I don't know very well the possible impacts of the proposed changes.

My question is: Given that Mintty is the default terminal emulator for MSYS2 environments and has support even for 24-bit colors, should not we set Term=xterm-256color on /etc/minttyrc, which seems to be described on this file https://github.com/msys2/MSYS2-packages/blob/master/mintty/minttyrc?

Tip

I am aware that each user can make such config changes by placing Term=xterm-256color on ~/.minttyrc.

My question is grounded on a few facts:

• MSYS2 supports Windows 10+ (maybe 8.1?). So, I don't see much of a problem on setting xterm-256color on such recent OSes;

• Ubuntu 24.04 (gnome terminal) uses xterm-256color by default. Probably, most recent distros too.

• If you open a cmd prompt on MSYS2 install folder (assuming an unmodified standard install at C:\msys64), and echo the TERM environment variable on bash through mintty, you get xterm as a response. On the other hand, if you echo TERM through bash directly, you get xterm-256color. So, it seems like that the default TERM used by bash is xterm-256color, and mintty is just overriding it:

Drawbacks

Quoting from mintty wiki:

The xterm−256color setting enables 256-color mode in some applications, but may not be recognised at all by others, which is why plain xterm is the default.

However, I'm not sure how well it applies for the MSYS2 environments.

Benefits

Bash script used below:

#!/usr/bin/bash

for c in {0..255}; do
    tput setaf ${c};
    echo -n "$c ";
done;

tput sgr0;
echo;

• In the current setup with xterm

• When xterm-256color is enabled

[eabase]

I was just wondering about this myself. My suspicion is that the defaulter directory file highlights, ls --color=always, grep --color=always and less with color-highlight package, breaks. I recently got the legacy warning about using old style color coding, which is the only one reliable.

[lazka]

I've created #5201 for this.

I was just wondering about this myself. My suspicion is that the defaulter directory file highlights, ls --color=always, grep --color=always and less with color-highlight package, breaks. I recently got the legacy warning about using old style color coding, which is the only one reliable.

Could you be more specific on what could break with this? I'm not seeing any issues at least, but have only done limited testing.

[eabase]

Hi Christoph,

Could you be more specific on what could break with this? I'm not seeing any issues at least, but have only done limited testing.

No, not more than try to use any of those additional colors with coloring ls, grep, nano and less -R. I recall having issues there, but not exactly what, so I reverted to default/limited palette. That said, and IIRC, TERM=xterm still supports 24-bit ANSI colors.

[lazka]

A somewhat related problem, #1596 mouse input is not working except with xterm-vt220. In case someone has any ideas.

[eabase]

@lazka
Ha, I think that's the issue I had. Scrolling the mouse was producing nothing (or garbage?) when using it in nano. Looks like (I didn't try it) the workaround for the above issue is by adding a custom $HOME/.terminfo using:

infocmp xterm-256color | sed -E 's/(kmous=\\E\[)</\1M/' | tic -o ~/.terminfo -

Which effectively replaces: kmous=\E[< with kmous=\E[M. However, I cannot find the meaning of that ANSI / CSI. Is it custom?

[lazka]

Which effectively replaces: kmous=\E[< with kmous=\E[M. However, I cannot find the meaning of that ANSI / CSI. Is it custom?

that seems to be SGR mouse tracking vs basic mouse tracking (xterm-vt220 forcing the basic one). In case of mc it turned out to be an upstream issue, see #5205. Maybe it's something similar with nano, so an application issue, after all.

[lazka]

though scrolling nano is working here @eabase

[eabase]

I just tested very briefly and it seem to work fine on my side.

# echo $TERM; export TERM=xterm-256color
# for c in {0..255}; do tput setaf ${c}; echo -n "$c "; done; tput sgr0; echo;

👍