bump rouge to 2.0.x

[Crunch09]

Hi,

this bumps rouge to 2.0.x as discussed in #4891 (comment) .

I used the HTMLLegacy formatter to avoid breaking changes but there are some minor ones as you can see in the tests (no text-align: right; on the td of the line number for example). If this is not okay, i think we would have to write our own formatter.

[Crunch09]

Not sure here if we should choose ~> 2.0.5 or ~> 2.0

[envygeeks]

s.add_runtime_dependency(">= 1.7", "< 3") == "1.x", "2.x"

[envygeeks]

I'm sorry but this pull in it's current form is unacceptable for 3.x. You _must_ allow 1.x (Rouge) to remain and work around Rouges changes in order for this to be accepted in 3.x as it's a breaking change that affects people, plugins and other stuff. This is what I had tried to imply was the problem on talk.jekyllrb.com, it's just too much work, without a wrapper of which we should have built long ago.

[envygeeks]

Either way, if you are willing to fix the problem so that both 1.x and 2.x work then it can be accepted in 3.x but until then it has a 👎 from me, because I do not wish to deal with upgrading the hundreds of plugins we have on our own sites that use Rouge 1.x in some way before absolutely necessary and even if I do, I do not wish to have to do it overnight because Jekyll decided to randomly upgrade a major dependency.

[parkr]

@envygeeks Point taken – I proposed we do this for 3.3 after it was shot down for 3.2 due to timing (#4891 (comment)). I'm 👍 on doing this if it's backwards-compatible. Could we check Rouge::VERSION?

[Crunch09]

Thanks for the feedback! Will try to make it work with rouge 1.x

[Crunch09]

Making some good progress on this!
But i am not sure which Formatter we should choose for 2.x ? I guess we don't need to use the Rouge::Formatters::HTMLLegacy formatter because users who want this behaviour are still free to use Rouge ~> 1.7.

[pathawks]

This was much easier to read before. Is there a reason this needed to be changed?

[Crunch09]

The only reason here was to be consistent with the test on line 318.

[pathawks]

Fixes #5556

[jneen]

Hi! What I recommend doing is actually defining your own formatter, especially if there are special things you want it to do. You can look through the existing formatters as well as the Gitlab Formatter. Alternately, you can use Formatters::HTML to generate plain unadorned HTML and add stuff around it as you like. Looking at the code you have, you might also consider using Formatters::HTMLTable, which takes an inner formatter (Formatters::HTML in your case) and a number of line numbering options.

[jneen]

Ah yes, and if you want to support both 1.x and 2.x, you'll have to define a wrapper, as the APIs are different.

[Crunch09]

@jneen Thank you!

[fliiiix]

@Crunch09 are you working on it?

[Crunch09]

@fliiiix Yes. Sorry for the delay, it's been a busy couple of weeks but there should be an update by the end of the weekend.

[Crunch09]

@jekyll/core Unfortunately i still have some open questions regarding this and i hope you can help to clear them up so i can push an update:

• If we write our own formatter, should it produce the exact same output as now with Rouge 1.7? If not, what should / is allowed to change compared to the current version? I guess if we were to change some things this wouldn't be a breaking change for users as they still could use the old Rouge version.
• If we want to land this in jekyll 3.4 and support both Rouge versions should there be different CI builds to test against each version?

[parkr]

Fixes #5774.

[willclarktech]

Hi, is there any movement on this? Currently code highlighting of ES6 template literals are broken on GitHub Pages sites because rouge 1.x doesn’t support them.

[pathawks]

If we write our own formatter, should it produce the exact same output as now with Rouge 1.7? If not, what should / is allowed to change compared to the current version? I guess if we were to change some things this wouldn't be a breaking change for users as they still could use the old Rouge version.

If a user has Rouge 1.x installed, the output should be unchanged. If a user has Rouge 2.x installed, they should be aware that the output might be different.

If we want to land this in jekyll 3.4 and support both Rouge versions should there be different CI builds to test against each version?

I don't think we need to double the size of our matrix, but we should have at least one that tests with the old Rouge and at least one that tests with the new. Probably only have one that tests against Rouge 1.x and move everything else to 2.x?

[Crunch09]

@pathawks Thank you for the clarification, that should help!

[guymorita]

Can we get this merged in? Would help lots. Thanks.

[Crunch09]

@guymorita Hi, please see #6150 for updates.