Re: cgit syntax highlight request
> ... > The unscientific survey does lean toward adding color syntax > highlighting. Therefore I have enabled it on the cgit interface for > at least an experimental basis. It is active now. This uses the > "highlight" utility. This identifies file types by file suffix. > ... This is great, thanks David pgpjCLBTl89CO.pgp Description: OpenPGP digital signature
cgit syntax highlight request
Thanks to everyone who added comments to this topic. It's been a week for people to think about things and make comments. (And a week for me to be completely consumed by my own tasks.) The unscientific survey does lean toward adding color syntax highlighting. Therefore I have enabled it on the cgit interface for at least an experimental basis. It is active now. This uses the "highlight" utility. This identifies file types by file suffix. http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/cat.c Let me say that I would prefer not to colorize just like the people who commented they preferred no color. Adding this is definitely not the most natural thing for me to be doing. But I think highlight does a pretty good job of enhancing the syntax without being overpowering. And very importantly in both dark and light themes. For all of us in the no-color camp I can point out that gitweb is still no-color and still available for us to use. Also my take of the people who voted this way is that we might all be people more comfortable working in our own sandbox where we have our own environments set up. The web interface perhaps being the shared commons for people not using their own sandbox. http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f=src/cat.c In any case let's take the highlighting out for a shake down cruise and see how it works for all of us. If you love it then please make a comment to that effect. If you hate it then also make a comment to that effect. This might be a good opportunity for someone to get involved with cgit and develop a nice way to allow users to choose color highlighting or not. I know I would use that control knob. Bob
Re: cgit syntax highlight request
Hello, > I vote for no color. I vote for colorizing, and i agree that highlight is a better choice (it also does a better job imo). But this said, is it not possible to write a script, that the savannah admin could pass/use to configure cgit syntax-highlighting, that would first check for a project variable that we (savannah users) could set on a per project base, and that var would be set to #f by default? > Even the URL that was brought up by the advocates of coloring > ... I actually did paste the link to show, to those who asked in the #savannah if it was possible to configure cgit to do so ... but it's a bit unfortunate to use it as a bad syntax-highlighting' (counter)example because it is a guix config file ... not a 'pure scheme file [1] David [1] guix has numerous syntax and struct def that would probably needs custom treatments even emacs sometimes needs 'an update' for its scheme mode - I recently asked to add a change to the scheme.el mode, because in G-Golf, I added a define-vfunc syntax and i wich it syntax-highlight those forms as it does for define-method ... pgpb7vfNaSCnF.pgp Description: OpenPGP digital signature
Re: [Savannah-hackers-public] cgit syntax highlight request
On Fri, Apr 28, 2023 at 4:45 PM Ian Kelling wrote: > > > Bob Proulx writes: > > > [[PGP Signed Part:Undecided]] > > Savannah Users, > > > > A user on IRC (daviid) has requested that cgit on Savannah be modified > > to perform syntax highlighting by default on the various source page > > display pages. > > > > I did some research into this topic of cgit syntax highlighting. It Thanks for looking into it. > > seems there are two popular ways to enable syntax highlighting in > > cgit. One uses the Python "Pygments" and one uses the standalone > > "highlight" utility. > > > > On IRC there were various comments about pygments and previous > > security vulnerabilities it has been through. The other option using > > "highlight" I note is packaged for Debian and therefore if any > > security vulnerabilities were found that the security channel would > > normally provide a patch which would be quickly installed on our > > systems. Therefore in my opinion using "highlight" would be the best > > option. > > I agree. I actually got a patch into git for it's gitweb interface so > that it uses highlight as it's syntax highlighter. I think it used > pygments before, I can't remember for sure. Anyways, I did it because > highlight detected bash scripts and highlighted them, whereas the > previous highlighter did not. I also agree. > > > > > I tried it with both dark and light themes and it seems acceptable in > > either. Which is important to me personally as I almost always use a > > dark theme when possible. > > > > Personally I rather prefer the non-colorized display. Colors are one > > of those bike-shed items that everyone wants to be different. > > Therefore the common ground is often the no-color option. I much > > prefer if people clone to their own sandbox and then they can use > > their own preferences for all bike-shed things like colors and fonts. > > But this is a shared resource and everyone is using it as a commons > > area. I will bring the topic up for discussion. > > > > What is the opinion of the group at this time? Should we enable > > syntax color highlight in cgit by default? > > I'd prefer colorized output, but, first you should check the resource > use. When I made the git change, I found that highlight and pygments (i > think) had roughly equivalent performance, but I was surprised how much > cpu time they took up. So, I suggest check the page load time difference > for a few files: the extra time will be 100% cpu use of a forked > process. +1 for all of this. Especially, I also like colors and will pay CPU loads some attention, if we start giving them. > > > Should we leave color as > > it is now without? Should we try it for a time period and see how it > > is received? What would the users like to see here? > > My preference is to enable this on an experimental basis, watching it closely when we turn it on and, perhaps, taking discussing further analysis and thoughts regularly, such as as a standing point at the volunteer meeting for a few occurrences (ie, until terminated or deemed stable). > > Bob > > > > [[End of PGP Signed Part]] > >
Re: cgit syntax highlight request
I vote for no color. > Colors are one > of those bike-shed items that everyone wants to be different. > Therefore the common ground is often the no-color option. I much > prefer if people clone to their own sandbox and then they can use > their own preferences for all bike-shed things like colors and fonts. > But this is a shared resource and everyone is using it as a commons > area. Well said. A wrong coloring is much more confusing than a correct coloring is helpful. And a wrong coloring can occur when - a file name does not contain code in the programming language hinted by the suffix, or - the developers used syntax extensions (e.g. C macros, @FOO@ autoconf variables that get substituted, etc.), or - the coloring algorithm is too simplistic in the first place. Even the URL that was brought up by the advocates of coloring https://git.dthompson.us/guix-config.git/tree/takemi.scm#n165 shows deficiencies: In line 28, the identifier 'extension' is bold, but in line 33 it is not. Bruno
Re: cgit syntax highlight request
Should we leave color as it is now without? I vote for "no color". In the alternative, I'm in full agreement with using highlight, not Pygments, for the reasons stated (which I've also experienced). --thanks, karl.
Re: cgit syntax highlight request
Bob Proulx writes: > [[PGP Signed Part:Undecided]] > Savannah Users, > > A user on IRC (daviid) has requested that cgit on Savannah be modified > to perform syntax highlighting by default on the various source page > display pages. > > I did some research into this topic of cgit syntax highlighting. It > seems there are two popular ways to enable syntax highlighting in > cgit. One uses the Python "Pygments" and one uses the standalone > "highlight" utility. > > On IRC there were various comments about pygments and previous > security vulnerabilities it has been through. The other option using > "highlight" I note is packaged for Debian and therefore if any > security vulnerabilities were found that the security channel would > normally provide a patch which would be quickly installed on our > systems. Therefore in my opinion using "highlight" would be the best > option. I agree. I actually got a patch into git for it's gitweb interface so that it uses highlight as it's syntax highlighter. I think it used pygments before, I can't remember for sure. Anyways, I did it because highlight detected bash scripts and highlighted them, whereas the previous highlighter did not. > > I tried it with both dark and light themes and it seems acceptable in > either. Which is important to me personally as I almost always use a > dark theme when possible. > > Personally I rather prefer the non-colorized display. Colors are one > of those bike-shed items that everyone wants to be different. > Therefore the common ground is often the no-color option. I much > prefer if people clone to their own sandbox and then they can use > their own preferences for all bike-shed things like colors and fonts. > But this is a shared resource and everyone is using it as a commons > area. I will bring the topic up for discussion. > > What is the opinion of the group at this time? Should we enable > syntax color highlight in cgit by default? I'd prefer colorized output, but, first you should check the resource use. When I made the git change, I found that highlight and pygments (i think) had roughly equivalent performance, but I was surprised how much cpu time they took up. So, I suggest check the page load time difference for a few files: the extra time will be 100% cpu use of a forked process. > Should we leave color as > it is now without? Should we try it for a time period and see how it > is received? What would the users like to see here? > > Bob > > [[End of PGP Signed Part]]
Re: cgit syntax highlight request
Bob Proulx wrote: > I did some research into this topic of cgit syntax highlighting. It > seems there are two popular ways to enable syntax highlighting in > cgit. One uses the Python "Pygments" and one uses the standalone > "highlight" utility. > > On IRC there were various comments about pygments and previous > security vulnerabilities it has been through. The other option using > "highlight" I note is packaged for Debian and therefore if any > security vulnerabilities were found that the security channel would > normally provide a patch which would be quickly installed on our > systems. Therefore in my opinion using "highlight" would be the best > option. Fwiw, I've used highlight (via libhighlight-perl bindings) and never had any segfaults for ~4 years now on a heavily-crawled site, so I'm pretty happy with it :> I'm using Debian stable on 32-bit x86 userspace, though, haven't tried 64-bit, yet, but intend to on a different system, soonish... I don't have any experience with pygments; but the Python core developers constantly breaking compatibility puts me off using things written in Python.
cgit syntax highlight request
Savannah Users, A user on IRC (daviid) has requested that cgit on Savannah be modified to perform syntax highlighting by default on the various source page display pages. I did some research into this topic of cgit syntax highlighting. It seems there are two popular ways to enable syntax highlighting in cgit. One uses the Python "Pygments" and one uses the standalone "highlight" utility. On IRC there were various comments about pygments and previous security vulnerabilities it has been through. The other option using "highlight" I note is packaged for Debian and therefore if any security vulnerabilities were found that the security channel would normally provide a patch which would be quickly installed on our systems. Therefore in my opinion using "highlight" would be the best option. I tried it with both dark and light themes and it seems acceptable in either. Which is important to me personally as I almost always use a dark theme when possible. Personally I rather prefer the non-colorized display. Colors are one of those bike-shed items that everyone wants to be different. Therefore the common ground is often the no-color option. I much prefer if people clone to their own sandbox and then they can use their own preferences for all bike-shed things like colors and fonts. But this is a shared resource and everyone is using it as a commons area. I will bring the topic up for discussion. What is the opinion of the group at this time? Should we enable syntax color highlight in cgit by default? Should we leave color as it is now without? Should we try it for a time period and see how it is received? What would the users like to see here? Bob signature.asc Description: PGP signature
