Project

General

Profile

Task #4289

Updated by Daniel D over 7 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