Pavan Kumar Sunkara <> 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
More majordomo info at

Reply via email to