Task #4289
Updated by Daniel D about 8 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`