[refactor] use termcolor crate instead of ansi

[HerringtonDarkholme]

Using ansi will make some windows client unhappy because cygwin like terminals does not support ansi but using console api.

[pd4d10]

Is this refactor started? If not I'd like to take it

[HerringtonDarkholme]

Nope, it is not started. Happy to see you are interested but would you like to provide a high-level plan for the refactor?
It will be quite huge.

[pd4d10]

Sure, I'll look into it.

[pd4d10]

After doing some research, I found that the usage of termcolor is a little different from other libraries (with just ANSI support), because it aims to support the Windows console API, which also means it seems difficult to log texts with different styles in one same statement. For example:

// the styles of header and message are different
writeln!(w, "{header} {message}");

should be firstly refactored into

write!(w, header);
writeln!(w, " {message}");

So I think the refactor could be split into two steps:

1. Following the example above, refactor all the existing print stuff.
2. Finish the ansi_term -> termcolor replacement.

The trade-off is that we would lose some intuitiveness when doing print stuff in the future.

What do you think?

[HerringtonDarkholme]

Nice writeup! I wonder if we can test the huge refactor accordingly? If the end user is not impacted by the change, I would opt for termcolor since it also supports windows console API.

[pd4d10]

if we can test the huge refactor accordingly

Yeah, we can firstly improve the test coverage, which is currently 60% according to the badge at README, then do the refactor.

[HerringtonDarkholme]

Yeah! Sure!

[pd4d10]

It seems that we already have tests, but there is no check for the color. For example

ast-grep/crates/cli/src/error.rs

Lines 254 to 289 in d9ebbe5

	mod test {
	use super::*;
	#[test]
	fn test_display_error() {
	let error = anyhow::anyhow!("test error").context(ErrorContext::ReadConfiguration);
	let error_fmt = ErrorFormat {
	context: &ErrorContext::ReadConfiguration,
	inner: &error,
	};
	let display = format!("{error_fmt}");
	assert_eq!(display.lines().count(), 6);
	assert!(display.contains("Cannot read configuration."));
	assert!(
	display.contains("Caused by"),
	"Should display the error chain"
	);
	assert!(display.contains("test error"));
	}
	#[test]
	fn test_bare_anyhow() {
	let error = anyhow::anyhow!(ErrorContext::ReadConfiguration);
	let error_fmt = ErrorFormat {
	context: &ErrorContext::ReadConfiguration,
	inner: &error,
	};
	let display = format!("{error_fmt}");
	assert_eq!(display.lines().count(), 3);
	assert!(display.contains("Cannot read configuration."));
	assert!(
	!display.contains("Caused by"),
	"Should not contain error chain"
	);
	}
	}

I guess we can use snapshot to avoid hard code such as "\u1b[31" in the test cases. A lib named insta seems to meet our needs.

Shall we use it or just do the hard code in test cases, what do you think?

[RReverser]

Would this also help with fixing color support on Windows? Currently --color says it default to auto which is described as

      - auto:   Try to use colors, but don't force the issue. If the output is piped to another program, or the console isn't available on Windows, or if TERM=dumb, or if `NO_COLOR` is defined, for example, then don't use colors

but I don't know what "console isn't available on Windows" means. I'm on Windows 11 and I always have to manually provide sg --color ansi to get colors in Windows Terminal as well as VSCode terminal, which gets a bit annoying to have to remember.

[HerringtonDarkholme]

Would this also help with fixing color support on Windows?

I do know if using termcolor should somehow fix Windows usage. Windows Terminal and VSCode terminal accepts ansi color so --color ansi.

I believe termcolor supports Windows console API which supports color natively without using ANSI escape code. Unfortunately, I don't have Windows machine to test the behavior of termcolor :(

I would try to refactor usage in future so external contributors can test termcolor.

[RReverser]

Windows Terminal and VSCode terminal accepts ansi color

More specifically, it's accepted by Windows itself (in ConPTY component which other terminals build on) since Windows 10, not by individual apps. Unless you want to support old Windows versions (which hopefully shouldn't be necessary for developers), it makes just defaulting to ANSI colors a much easier cross-platform option.

[RReverser]

There is some Windows API you'll still need to check if colors are supported (e.g. to make sure it's not a redirect or something), but I believe one of these crates should already handle that for you.

[HerringtonDarkholme]

Sounds good. I will investigate it. Changing default color is tracked by #680

[HerringtonDarkholme]

ansi color is the default color option in Windows since 0.13.1!

[RReverser]

Thanks!