patch 9.1.1114: enabling termguicolors automatically confuses users
Problem: enabling termguicolors automatically confuses users. Since
querying the terminal for the RGB flag happens asynchronously,
enabling termguicolors is noticeable by users as the highlighting changes
and is therefore unexpected.
(after v9.1.1054)
Solution: comment out that part for now. We may need another way to
enable this in the future.
fixes: #16539
fixes: #16568
fixes: #16649
Signed-off-by: Christian Brabandt <cb@256bit.org>
diff --git a/src/term.c b/src/term.c
index 318b982..ea4c22d 100644
--- a/src/term.c
+++ b/src/term.c
@@ -1661,11 +1661,13 @@
sprintf((char *)nr_colors, "%d", t_colors);
else
*nr_colors = NUL;
+#if 0
#ifdef FEAT_TERMGUICOLORS
// xterm-direct, enable termguicolors, when it wasn't set yet
if (t_colors == 0x1000000 && !p_tgc_set)
set_option_value((char_u *)"termguicolors", 1L, NULL, 0);
#endif
+#endif
set_string_option_direct((char_u *)"t_Co", -1, nr_colors, OPT_FREE, 0);
}
@@ -1701,7 +1703,9 @@
# ifdef FEAT_TERMRESPONSE
// Do those ones first, both may cause a screen redraw.
"Co",
- "RGB",
+ // disabled, because it switches termguicolors, but that
+ // is noticable and confuses users
+ // "RGB",
# endif
"ku", "kd", "kr", "kl",
"#2", "#4", "%i", "*7",
@@ -7197,6 +7201,7 @@
#endif
may_adjust_color_count(val);
}
+#if 0
#ifdef FEAT_TERMGUICOLORS
// when RGB result comes back, it is supported when the result contains an '='
else if (name[0] == 'R' && name[1] == 'G' && name[2] == 'B' && code[9] == '=')
@@ -7214,6 +7219,7 @@
}
}
#endif
+#endif
else
{
i = find_term_bykeys(str);