Output is not deterministic

[neersighted]

The output of vivid generate is not deterministic -- subsequent runs differ. Scenarios where the output of Vivid is cached (or used in an idempotent script) could be improved by making the output deterministic.

[sharkdp]

Thank you for reporting this.

output is not idempotent

Do you mean: the output is not deterministic?

If so, you are absolutely right. I did not know that. It's probably due to the use of hash maps. I agree that this would be worth fixing.

That's probably even a bug, because the order of entries in LS_COLORS matters in case of conflicts:

touch test.txt
LS_COLORS='*.txt=0;31:*.txt=0;33' ls --color
LS_COLORS='*.txt=0;33:*.txt=0;31' ls --color

[neersighted]

Err, yes, I crossed a wire there. Non-deterministic results make idempotent use of vivid in scripts difficult.

The use of HashMaps makes sense -- an ordered collection would probably easily fix this (but then, the real question becomes what the 'correct' order is).

[sharkdp]

Err, yes, I crossed a wire there. Non-deterministic results make idempotent use of vivid in scripts difficult.

👍

The use of HashMaps makes sense -- an ordered collection would probably easily fix this

Yes. (Maybe it's also the YAML deserialization.)

but then, the real question becomes what the 'correct' order is

I think we shouldn't care too much about this question and rather implement a conflict-detection, if that is needed.

If there are two patterns like *.txt and *CMakeLists.txt (which needs the glob star in the beginning, unfortunately), we should make sure that the second one has precedence in case there is a file called CMakeLists.txt. But I think this is already guaranteed by the LS_COLORS "format" (or the reference implementation in ls) - but this should be checked again.

If there are really two *.txt patterns, this should be an error.

[tavianator]

If there are two patterns like *.txt and *CMakeLists.txt (which needs the glob star in the beginning, unfortunately), we should make sure that the second one has precedence in case there is a file called CMakeLists.txt. But I think this is already guaranteed by the LS_COLORS "format" (or the reference implementation in ls) - but this should be checked again.

Not really, ls is strictly last-match-wins:

Vivid should probably sort the suffixes from shortest to longest so that the most specific one will match.

[tavianator]

Vivid should probably sort the suffixes from shortest to longest so that the most specific one will match.

Oh, it already does:

vivid/src/main.rs

Lines 193 to 194 in 700c9a6

	let mut filetypes_list = filetypes.mapping.keys().collect::<Vec<_>>();
	filetypes_list.sort_unstable_by_key(|entry| entry.len());