Feature Request: Ignore unknown extensions --language is specified

[eriq-augustine]

Since mixing languages is not allowed, it would be nice if extensions were ignored (and language assumed) when the --language flag is present.

This would allow any lesser known extensions to pass through without issue.
For example, the c++ parser currently recognizes .cxx, but not .hxx:
https://github.com/jplag/JPlag/blob/main/languages/cpp/src/main/java/de/jplag/cpp/CPPLanguage.java#L21

A more common use case that I run into is that I want to just run a text-based analysis (with the text language), but very few extensions are supported:
https://github.com/jplag/JPlag/blob/main/languages/text/src/main/java/de/jplag/text/NaturalLanguage.java#L29

[tsaglam]

We will take a look at these cases. As a workaround, you can try to use -p to specify the file extensions:

-p, --suffixes=[,...]
comma-separated list of all filename suffixes that are included.

[eriq-augustine]

That should definitely work as a workaround.

I'm wondering if checking for a "valid suffix" is even necessary.
Since specifying a language is required (when unspecified it implicitly sets the language to java), checking extensions seems a bit redundant.
But, I think the extensions could be useful to guess the language.

Of course this is outside the scope of this issue, but does a system that guesses the language using a file's extension when --language is not supplied make sense for this project?

[tsaglam]

I'm wondering if checking for a "valid suffix" is even necessary. Since specifying a language is required (when unspecified it implicitly sets the language to java), checking extensions seems a bit redundant. But, I think the extensions could be useful to guess the language.

The problem is that projects may or may not contain many different file types, such as build scripts, resources, configuration files, etc. The valid suffixes are used to decide which files are passed to the parser, and without that, the user would receive many warnings/errors from the parser for obviously incompatible files.

Of course this is outside the scope of this issue, but does a system that guesses the language using a file's extension when --language is not supplied make sense for this project?

Currently, the default language is Java, which is used when no language is specified (solely due to historical reasons).
However, we have plans for multi-language support, which would entail that the default language parses all files that conform to the set of languages that JPlag supports.