Re: [PATCH] gitweb: Added syntax highlight support for golang
- From
Pavan Kumar Sunkara <pavan.sss1991@gmail.com>
- Date
- Feb 7, 2014, 23:10 UTC
- Message-ID
- <CAK9CXBWiaORDJaTam=X02UiBCsF2m_kW33_DqbQSLfoY1JphiQ@mail.gmail.com>
- In-Reply-To
- <xmqqa9e2ttln.fsf@gitster.dls.corp.google.com>
Yeah. I agree with you.
I am currently looking into allowing users to customize the parameters given to their highlighter. I will try to look into this.
Thanks
On Sat, Feb 8, 2014 at 4:31 AM, Junio C Hamano <gitster@pobox.com> wrote:
Show 33 quoted lines
> Pavan Kumar Sunkara <pavan.sss1991@gmail.com> 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'".
-- - Pavan Kumar Sunkara