Pygments, a generic syntax highlighter(pygments.org)
pygments.org
Pygments, a generic syntax highlighter
http://pygments.org/
12 comments
> Yay, a major project using hg instead of git. This makes it seem like my work on hg is still worth something (as are the pull requests I have sent to pygments).
Mostly because nobody spend time to make the move. All other pocoo projects move to git (Flask, Werkzeug, Jinja2, Click, Sphinx, etc.).
Mostly because nobody spend time to make the move. All other pocoo projects move to git (Flask, Werkzeug, Jinja2, Click, Sphinx, etc.).
Aw. So you have no intent on staying with hg? I thought Georg Brandl was a big hg fan. :-(
And hg is so cool! Templates! Revsets! Evolve! Extensibility!
http://jordi.inversethought.com/blog/customising-mercurial-l...
https://www.youtube.com/watch?feature=player_embedded&v=NSLv...
https://www.youtube.com/watch?v=4OlDm3akbqg
http://jordi.inversethought.com/blog/x-men-in-mercurial-evol...
And hg is so cool! Templates! Revsets! Evolve! Extensibility!
http://jordi.inversethought.com/blog/customising-mercurial-l...
https://www.youtube.com/watch?feature=player_embedded&v=NSLv...
https://www.youtube.com/watch?v=4OlDm3akbqg
http://jordi.inversethought.com/blog/x-men-in-mercurial-evol...
Whether or not hg is good or even better than git is pretty much irrelevant at this point.
Github's popularity has made all other project hosting platforms irrelevant. Git's popularity means that every potential contributor knows how to use it, which significantly reduces friction for new ones.
Github's popularity has made all other project hosting platforms irrelevant. Git's popularity means that every potential contributor knows how to use it, which significantly reduces friction for new ones.
I don't buy the popularity argument. If I were to abandon software just because it wasn't as popular as the alternative, I would have to stop working on GNU Octave in favour of Matlab, and I would have to wipe GNU/Linux from my machines and just use Mac OS X or Windows.
I understand that git transcends organisation, programming languages, and operating systems. I still don't want to be stuck to the git way of doing things, no matter how popular it is. Concessions have to be made for git users coming to hg, but there are some things that hg does that git just will probably never be able to.
I may one day work on improving hgit, which is an hg front-end to a git storage backend proof-of-concept, but so far the hg-git workaround for git's popularity is good enough for most purposes.
I understand that git transcends organisation, programming languages, and operating systems. I still don't want to be stuck to the git way of doing things, no matter how popular it is. Concessions have to be made for git users coming to hg, but there are some things that hg does that git just will probably never be able to.
I may one day work on improving hgit, which is an hg front-end to a git storage backend proof-of-concept, but so far the hg-git workaround for git's popularity is good enough for most purposes.
Popularity is a strong argument. It's however not the only argument. In the case of git and hg popularity is important because the other arguments are too weak to matter in comparision.
That's not the case for GNU Octave or Linux. Those offer significant financial, ideological and technical benefits over alternatives. Benefits a large part of their user base actually cares about. Hg doesn't have that luxury. Git is simply good enough and hg is not good enough to offset the cost for choosing the unpopular option.
That's not the case for GNU Octave or Linux. Those offer significant financial, ideological and technical benefits over alternatives. Benefits a large part of their user base actually cares about. Hg doesn't have that luxury. Git is simply good enough and hg is not good enough to offset the cost for choosing the unpopular option.
By this logic, Java and .net and php and sql are all irrelevant because all the cool kids use nodejs and mongodb, right?
The HN crowd loves to chase what's "trendy" without thought for if it's a good fit for their problem.
GitHub frankly is a terrible solution for anything but an open source project, and even then there are plenty of better alternatives.
if your project relies on the popularity of GitHub to attract contributors I would be more worried about the nature of your contributors than where the code is hosted.
The HN crowd loves to chase what's "trendy" without thought for if it's a good fit for their problem.
GitHub frankly is a terrible solution for anything but an open source project, and even then there are plenty of better alternatives.
if your project relies on the popularity of GitHub to attract contributors I would be more worried about the nature of your contributors than where the code is hosted.
Not at all. Java, .NET, PHP and SQL all offer features that Node.JS and MongoDB do not.
I also don't think that GitHub is a universally perfect solution. It's clearly not and I never said they were.
Using GitHub's popularity as a marketing measure is also not a binary choice between not using it at all and relying on it completely.
I also don't think that GitHub is a universally perfect solution. It's clearly not and I never said they were.
Using GitHub's popularity as a marketing measure is also not a binary choice between not using it at all and relying on it completely.
Mercurial offers features Git doesn't, but you claimed that's irrelevant because of the network effect of GitHub
I think for an open source project git itself has some nice features that are severely lacking in hg. Since I switched to git I never looked back and handling of pull requests has become a breeze. In hg times I actually shuffled around with mq and manually applied patches because managing other people's remotes in light of named branches was a nightmare.
I consider MQ one of hg's youthful mistakes, just like early git didn't have refs.
If your biggest complaint with hg is MQ, rejoice: there are modern alternatives that make MQ almost obsolete unless your current workflow already heavily depends on MQ.
If your biggest complaint with hg is MQ, rejoice: there are modern alternatives that make MQ almost obsolete unless your current workflow already heavily depends on MQ.
In the context of choosing a DVCS for an open source project.
Uh. Do you mean that, because a project is open source it has to limit itself to the lowest common denominator (not targeting git specifically here) rather than aspire to a better/more suited toolchain that its community believe in?
And by the community, I do not count those not having made any contribution but complaining about what is there in the first place.
This case is about the toolchain, but the same could be set about the code. Does it has to stick to an imperative form, as it is the most common widespread and understood paradigm, or can it be functional because it fits best the original design?
As long as the API is clean and the documentation is clear, I'm fine making the little extra effort to enter the world of the author rather than him/her lowering his/her expectation about what the project, as a whole, should be.
And by the community, I do not count those not having made any contribution but complaining about what is there in the first place.
This case is about the toolchain, but the same could be set about the code. Does it has to stick to an imperative form, as it is the most common widespread and understood paradigm, or can it be functional because it fits best the original design?
As long as the API is clean and the documentation is clear, I'm fine making the little extra effort to enter the world of the author rather than him/her lowering his/her expectation about what the project, as a whole, should be.
It's quite humorous to think about how Git's popularity is as a result of a platform that in many ways subverts its interface and even core architecture of being distributed. Is it a Pyrrhic victory, I cannot tell.
> Aw. So you have no intent on staying with hg? I thought Georg Brandl was a big hg fan. :-(
I don't know, but he moved Sphinx to git a month ago or so :)
I don't know, but he moved Sphinx to git a month ago or so :)
Mozilla still uses hg for their source control
As does Facebook, Google, and Python and a few not as big players. I've also heard rumours that the Facebook devs are trying to help other big companies move slow, gigantic git repos to faster gigantic hg repos.
Still, it's a bit hard for me to keep my chin up over hg when everyone seems to think that git is the ultimate word on DVCSes with no room for dissenting software. It warms my heart whenever I see another project using hg for real and not half-heartedly like Golang was doing... and now they're using git half-heartedly, oh well.
Still, it's a bit hard for me to keep my chin up over hg when everyone seems to think that git is the ultimate word on DVCSes with no room for dissenting software. It warms my heart whenever I see another project using hg for real and not half-heartedly like Golang was doing... and now they're using git half-heartedly, oh well.
For what it's worth, I think Hg is an easier sell to mid-size companies transitioning from SVN to a DVCS. With Git, you need to absorb a certain "git mentality" to really understand what all of the commands are; with Hg it seems like I just need to say "you COMMIT and UPDATE from this hidden folder on your drive, then you PUSH and PULL from that hidden folder to these other hidden folders in other places."
If it makes you feel better, at one point at this job I replayed a bunch of SVN changes through Hg because there were a bunch of independent updates that needed to be grouped into different branches, so that I could finally find out that the cause of the bugs in the code was that someone had changed `if (x == "true")` statements into `if (x)` statements...
If it makes you feel better, at one point at this job I replayed a bunch of SVN changes through Hg because there were a bunch of independent updates that needed to be grouped into different branches, so that I could finally find out that the cause of the bugs in the code was that someone had changed `if (x == "true")` statements into `if (x)` statements...
Thanks, that does make me feel better. :-)
If anyone is writing Clojure, you can use Clygments [1], a bridge to Pygments I wrote a year ago
[1]: https://github.com/bfontaine/clygments#clygments
[1]: https://github.com/bfontaine/clygments#clygments
Just the other day we added syntax hilighting to http://doc.perl6.org/ backed by pygments. Yay!
A few years ago i've converted some popular vim color schemes (Twilight, Wombat, Mustang,etc...) to pygments css styles: https://github.com/uraimo/pygments-vimstyles
Pygments for me has been easy to get working on my blog but extremely difficult and so far impossible for me to customize. My blog is Ruby based and so first of all I don't quite understand how a python program can be added as a ruby gem. Second, I really don't understand how to create my own lexer. Do I edit the Ruby gem? Do I need to create my own gem? If I edit the gem locally I may be able to do something but how do those edits get to Heroku? The task is much more complicated than I have the knowledge for.
I used Pygments to power the syntax colouring of ulisse (https://github.com/JulianBirch/ulisse) a Clojure documentation generator (specifically, a codox writer).
Here's some example output: http://julianbirch.github.io/arianna/arianna.html
Here's some example output: http://julianbirch.github.io/arianna/arianna.html
I switched to Pygments from a JS-based solution, and I highly recommend it. The parser is great and the resulting CSS and HTML are much cleaner.
What is the js based solution?
It was this: http://alexgorbatchev.com/SyntaxHighlighter/
Freenode #pocoo is also the channel were Flask users hang out.
I use it as LESSPIPE and it's very nice. The only problem is it is slow, so you can't view longer files immediately as in regular less.
> The only problem is it is slow, so you can't view longer files immediately as in regular less.
For most lexers this could be fixed to be iterative. The lexers can do iterative processing, it's just that the command line tool does a horrible job at supporting that.
For most lexers this could be fixed to be iterative. The lexers can do iterative processing, it's just that the command line tool does a horrible job at supporting that.
I should check it out sometimes, then. Thanks.
I think that REST service for Pygments would be a nice thing for solutions that could not run python scripts directly.
Interestingly enough, there is one unofficial API http://pygments.appspot.com/, but supports an outdated version (1.5).
Agda highlighting is as uninteresting as it can be.
It should be on par of the real Agda highlighting but it is not.
It should be on par of the real Agda highlighting but it is not.
How about you contribute this missing bit or improve it instead of whining on the internet? This is really a minor feature for pyglets (most people would use it for more mainstream stuff than Agda), so how about you take it over?
I love pygments, but I wish the C lexer were better and I wish it were written in C.
Btw, the next hg sprint will be at Pycon in Montréal!
http://mercurial.selenic.com/wiki/3.4sprint