Description
Description of the bug:
Some third-party Emacs packages (e.g. eat) provide terminal emulators where colour output with --color=yes works, which set INSIDE_EMACS but have their own TERM values, different from the built-in terminal's eterm-color. However, bazel's colour auto detection considers eterm-color the only colour-supporting terminal inside Emacs (link) - so --color=auto does the wrong thing in eat.
Not sure what the best solution here would be - denylist Emacs terminals known not to work rather than allowlisting ones that work? Checking terminfo for colour support?
A workaround is to unset INSIDE_EMACS when invoking bazel.
Which category does this issue belong to?
No response
What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
Set INSIDE_EMACS in a term other than eterm-color before invoking bazel.
Which operating system are you running Bazel on?
Ubuntu 24.04
What is the output of bazel info release?
No response
If bazel info release returns development version or (@non-git), tell us how you built Bazel.
No response
What's the output of git remote get-url origin; git rev-parse HEAD ?
If this is a regression, please try to identify the Bazel commit where the bug was introduced with bazelisk --bisect.
No response
Have you found anything relevant by searching the web?
No response
Any other information, logs, or outputs that you want to share?
No response