Depending on the way of producing Path instances, they are not always
relative paths. Therefore, use absolute paths in for all files tests
and use them also for the starts_with assertions. Otherwise,
the assertion simply cannot find the relative path in an absolute path
which can lead to miss a bug.
For a given target directory not only the .editorconfig files in it
are relevant for the files in it. The .editorconfig files from parent
directories can also be relevant.
This change effect the status command and the spelling_language check.
For both it seems more logical to me, that all .editorconfig files
of the considered files are in the scope.
Writting the status info via logging has the disadvantages,
that a higher verbosity is required to get any output and is not
suitable in case of using ecformat as lib crate.
Therefore, using a struct to return the status info, which provides
functions to get the text representation of the status for printing.
To allow usage also in other tests
Same as in SpellingLanguageHandler::build
Although, the language for the VSCodium extension LTeX+ is set already,
a general setting for the spelling language is may helpful when using
other editors to contribute to ecformat.
- Rename from get_path() to path() as the prefix is not common in Rust.
- Change the return type from &PathBuf to &Path as
this can be used more flexible.
To reduce the vebose proceding of all properties
There is only one string property and one integer (only) property.
Therefore, the full enums in the test cases for them are not necessary
to see what property it is and the primitve type is enough.
This reduces how verbose the respective test code is.
The CLI help has a section to "disable" EditorConfig properties.
Therefore, talking about enabled properties is more consistent.
Rename the status module to resolve the name clash
with the status function in the src/lib.rs.
This allows to use both in the same module, such as in src/lib.rs or
tests/status.rs.
Remove "redundant explicit link target",
"because label contains path that resolves to same destination"
(cites from the docs.rs warning).
The warnings the in status_types Unit Tests are not visible in VSCodium
(due to some error). They are listed with cargo clippy if the test
targets are included. However, the automatic runs of clippy do not
fail on warnings! Adding a CLI to make them failing as expected.
Allowing this clippy warning in all test code would be also fine.
However, the only way to do this seems to use compiler flafs for the
profile.test, but this feature is not stable in cargo yet, see issue:
https://github.com/rust-lang/cargo/issues/10271