Pavan Kumar Sunkara <pavan.sss1991@xxxxxxxxx> writes: > Sorry. I misunderstood your message. Yes, I guess lazy loading the > supported file extensions would be better. But not all highlighters > support `-p` option. So, I think its better to leave it to the user. Yes, those highlighters that do not support `-p` may have to rely on the hard-coded list %highlight_ext. But with the same line of reasoning, not all versions of highligher supports 'go' language, so it's better to leave that to the user, no? The version of 'highlight' you may have may know about 'go', and somebody else's 'highlight' may not yet. A hard-coded list that appears in %highlight_ext will be correct for only one of you while the other between you two needs to customize it to his system. Note that I was not talking about removing the configurability. Even with lazy loading and/or auto-genearting at build-install time when 'highlight -p' is available, the users still want to be able to customize, and supporting that is fine. But for those whose 'highlight' does support '-p', it will help to lazily discover the list of supported languages and/or enumarate them at build-install time. They do not have to keep adding new language (or removing it from the list we give as the upstream) to adjust it to their system. In any case, the comment was not about this patch from you, but about the future direction for the code it touches in general. In other words, it did not mean "because it does not update the mechanism to lazily discover the list of languages, and instead added yet another language to the existing one, it is not an acceptable solution to start supporting 'go'". -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html