Project

General

Profile

Task #4289

Updated by Daniel D about 4 years ago

Currently there are a few lexer functions that seem duplicated/incoherent with each other. This seems to be also tied with the rc extensions which can define custom lexers/file extension mappings

such as
in example-ext.py:

~~~

# =============================================================================
# END OF UTILITY FUNCTIONS HERE
# =============================================================================

# Additional mappings that are not present in the pygments lexers
# used for building stats
# format is {'ext':['Names']} eg. {'py':['Python']} note: there can be
# more than one name for extension
# NOTE: that this will override any mappings in LANGUAGES_EXTENSIONS_MAP
# build by pygments
EXTRA_MAPPINGS = {}

# additional lexer definitions for custom files it's overrides pygments lexers,
# and uses defined name of lexer to colorize the files. Format is {'ext':
# 'lexer_name'} List of lexers can be printed running:
# >> python -c "import pprint;from pygments import lexers;
# pprint.pprint([(x[0], x[1]) for x in lexers.get_all_lexers()]);"

EXTRA_LEXERS = {}
~~~

Then there are the functions get_custom_lexer and the FileNode attributes `filenode.lexer` which don't seem to follow the same logic - the filenode lexer for example seems to prefer a lexer matching the filename instead of a defined custom lexer.

We should use a common base for getting a lexer - one that first returns custom lexer mappings (so that for example .html can be mapped to mako).

Extending on this it could be possible to make the file extension => lexer mapping a per repository setting, exposed via the ui, which would give the best usability in terms of letting each repo specify which lexer to prefer ... again for example `.html => mako`

Back