Fix diff interactivefilter when decoration option is enabled

[ghost]

Fix #320 (comment)

When ***-decoration-style is enabled, it occurs error. So I set them to none while color-only.

Also, I added all configs to test(excluding show-config, show-syntax-theme, or something not related).

[ghost]

Apparently, these --line-numbers-*** is not necessary because line-numbers would be disabled. However, I can't make sure if the option's behavior will be changed, so I added anyway.

It's just my opinion.

[dandavison]

Hi @Ryuta69, thanks for this PR! I have one question: aren't these already set to "none" by the color-only feature? (see the way that feature "inherits" from the raw feature)

[ghost]

@dandavison
Thank you for review!
Oh, is that supposed to be? If so, currently it seems not working when a user supply some options in gitconfig.

In order to give priority to the options in features/** even when a user supply option in gitconfig, I think we must switch the conditions below (Of course only switching them would break some tests such as features::tests::test_main_section_overrides_feature. I still need extra check.)

delta/src/options/get.rs

Lines 54 to 72 in 1ca0615

	if let Some(git_config) = git_config {
	if let Some(value) = git_config.get::<Self>(&format!("delta.{}", option_name)) {
	return Some(value);
	}
	}
	for feature in opt.features.to_lowercase().split_whitespace().rev() {
	match Self::get_provenanced_value_for_feature(
	option_name,
	&feature,
	&builtin_features,
	opt,
	git_config,
	) {
	Some(GitConfigValue(value)) | Some(DefaultValue(value)) => {
	return Some(value.into());
	}
	None => {}
	}
	}

Currently, both not working as you suggested.

[delta]
	file-decoration-style = ul
# git diff | delta --color-only
# => It still prints file-decoration-style as ul.

------------

[delta]
	minus-style = blue
# git diff | delta --raw
# => It still prints minus-style as blue.

[dandavison]

Hi @Ryuta69, sorry to be slow -- I was meaning to look into what we're discussing here but didn't find time yet. Definitely looking forward to having this PR in the next release.

[ghost]

@dandavison
Sure! The first priority is your schedule, and I'll help when you have a time. Again, thank you for this great OSS.

[dandavison]

OK, this sounds like a potential headache -- let's just keep the hard-coded override to "none" that you have, and we can maybe worry in the future about whether the none-value was supposed to be inherited from the feature automatically.

[ghost]

@dandavison
I understand, thank you for review.
If I find a way to solve, I'm going to create PR.

[dandavison]

LGTM, thanks @ulwlu!

I pushed one commit a39b58c which removed the true arguments to the boolean flags, and deleted one dup test case. I believe that that "true" was not actually being used as an option value but rather was being interpreted as the first of two possible file name positional args. E.g. gs | delta --light true true "works" but gs | delta --light true true true fails with error: Found argument 'true' which wasn't expected, or isn't valid in this context. Let me know if anything in a39b58c doesn't seem right to you!

[ghost]

@dandavison
Oh! I didn't notice there is that kind of case.
thank you very much!