Add an explicit method to retrieve supported languages. #210
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The current way of retrieving a list of supported languages from CodeRay (using
CodeRay::Scanners.list
, see eg. the Stack Overflow question 'Getting the list of available languages') has two drawbacks/limitations:debug
,raydebug
,scanner
and potentially thedefault
alias);I can think of multiple use-cases where one wants to retrieve a list of supported languages, excluding the "internal" scanners and/or including the aliases. One is for example reported as #194.
Recently, Redmine introduced a change where such a list is needed too (revisions r16501 and r16502). While it is pretty easy to "generate" it downstream (redmine.org issues #25634 and #26055), it requires CodeRay integrators to reinvent the wheel over-and-over again. As such I think it would be handy if this functionality is provided by the CodeRay API itself.
I extracted a new, generalized class method (
CodeRay.supported_languages
) from the Redmine core, ported it to CodeRay and added some basic test coverage. The method has two optional arguments:include_aliases
(default totrue
);include_internals
(default tofalse
).These defaults are taken from Redmine's use-case and, as such, may not suit everyone's needs.