@Erik van Zijst, in #9238 you mention one of the reasons for not implementing syntax highlighting in diffs, that is—necessity to load the whole file to correctly highlight it. What about enabling highlighting in side-by-side diffs only? In the latter case the whole file is loaded anyway.
In the latter case the whole file is loaded anyway.
Actually, it's not. In side-by-side only the chunk that contains the visible portion is loaded. You can see this on large files when you quickly scroll down. You'll see that missing pages are swapped in through AJAX.
Its a huge PITA to read large PRs that are all in green!!! Again, github is doing it! You don't need the entire file to syntax highlight, you need to know the file type, which you do, and apply the highlighter to just that piece.
I've seen this functionality in stash (self-hosted bitbucket) for side by side only. I kind of expected it to be in bitbucket, which would presumably be a more up-to-date stash, but we don't have it here.
I'm here to complain, yada yada
Does anyone have an injectable work-around (grease monkey, etc...) until this is implemented?
Edit: In response to @Erik van Zijst's comment on the duplicate issue where he stated that there is trouble with performance in highlighting large files I see 2 possible solutions:
attempt to highlight syntax contextually by limiting the scope that is highlighted. If you have the proper context I think it should work... In other words truncate out some half methods and things that might cause problems, leave those parts unhighlighted and highlight "the most complete part." It's not pretty but something is better than nothing, yeah?
Don't highlight large files at all and display a message saying the file is too large. Generally large files are a code smell, anyway. If people really care enough about their highlighting they'll chop down the files themselves. Exactly how large is "large?" Either way I think it should handle most cases.
This is definitely something we want to add - it would be super useful for our own development - but as Erik said: "you often need to load up and then parse the entire contents of a file (as opposed to just the hunks that have changed) and this makes displaying large diffs substantially slower and we have so far been unsuccessful in getting acceptable performance." However, we're working toward a solution because the code review experience is a top priority for us.
There's something called file extensions. And yes I know it's not bulletproof, there can be files without extension, etc... But a file with the .c extension is C code 99% of the time, a file with the .php extension is PHP code 99% of the time, a file with .html extension is HTML code 99% of the time, a file with the .py extension is Python code 99% of the time, and I can go on all day.
@Marc González Majoral for sure, but the issue is not the file type, but when a hunk starts in the middle of comment, string, condition, etc. The highlighter is then essentially presented with syntactically incorrect input and the results are undefined. It is for this reason that to do diff highlighting reliably, we'd need to read and parse the entire file and not just the hunks and this is where performance comes in.
Now I do like @Gregory McQuillan's suggestion of offering diff highlighting for reasonably sized files only and that is certainly something we could try.
When you say "Syntax Highlighting" are we talking about highlighting language syntax errors? Or are we just talking about adding some color? If the latter, then I don't see the big deal, you already have it basically working in every single comment box, ie:
That's an interesting point but it might also be a fairly simple and straight forward code sample in the grand scheme of things.
As an example I've experienced similar behavior to what @Erik van Zijst is describing in vim. Specifically with PHP syntax highlighting in large files.
At some point it just gives up and dies and you end up with a file that is white and red and all sorts of weird colors.
Though I talk to some other people and they don't have this problem (I digress).
Vim also has a variable that can be set to change the number of maximum lines to highlight (a la syn sync maxlines=100).
So going with this approach, it could either partially highlight the file and give up, or just not even bother for entire files over a certain length.
Now I don't know exactly why that happens in an editor like vim, and not other editors like SublimeText or more powerful IDEs like Intellij but the trick there might be threading which is something that may or not be possible depending on bitbucket's backend technology.
Thinking about it from that perspective also makes me wonder if there's some sort of way that the files could be processed in the background by some other totally separate non-http "syntax highlighter" process and then just read in by it later.
Then again this also has some complications and just might be overkill...
Edit: I'm also really liking @André Mazoni Wanderley's solution, it's got some few flaws but I think it's improving already on that front :) nice work!
I recently published a new version that fixes all flaws, but there are still some interesting features to be done (like highlighting side-by-side diff, which I don't use often, that has different markup structure).
@Benjamin Echols glad to hear you note "This is definitely something we want to add" - but I also see the Priority for this is set to trivial... I understand some of the technical challenges you are having but I hope it can be considered a bit more than trivial... I think it helps with readability and speed of getting through PRs and even helps to catch a few things... I would think it is quite a useful feature, not trivial?
Sorry for the rant, but we effectively stopped doing code reviews because of this missing feature.
I'm only speculating, that this feature request is constantly being kept in a low priority state by the business side, because adding this would not generate any access profit for the product. But ffs, the feature have been requested in the December of 2013. How hard can it be to add highlight.js to the review page?
Someone asked, that "how should incorrect or partial code be formatted" and I say, that I can live with the fact, that the syntax highlighter might sometimes get glitchy compared to not having any syntax highlight at all.
We recently switched from Github to Bitbucket and this is my main gripe with Bitbucket at the moment. This issue does not seem to be taken seriously as this bug has been open for more than 4 years but it is a must-have feature for code review.
@Guilherme Pejon I think they envisioned something far more advanced than what was asked for here in this suggestion. I believe they wanted to create a linting highlighter whereas we just wanted a syntax highlighter. Big difference. But yes, they are taking their time for sure..!
It's definitely a prioritization failure. Like some other people mentioned before, even if the syntax highlighting wasn't perfect (for instance, multi-line comments not being highlighted properly), it would've been still incredibly useful and a huge improvement over the current code review experience.
It's more of a shock since there's already highlighting in source code view, and in the code review workflow of Bitbucket Server in some cases.
We licensed Crucible long ago for use with our old CVS and SVN repositories and it's really a great tool. I miss it every time I do a code review in BitBucket. You can set up your git repo in Crucible but it adds extra steps that interrupt smooth flow of pull requests.
I don't think Atlassian is trying to steer BB users to Crucible, but the priority for all code review improvements does seem low on their list.
The Bitbucket team is working on an improved pull request experience with the first phase launching in the coming months. We're aware of this request and will be looking to include this enhancement as this work progresses.
Please continue to follow this ticket for updates.