When reviewing suggested edits that have blocks of code that are long enough to scroll, I often find that I need to scroll up and down one side of the review to find a change, and then scroll the other side to try and match up where the user made an edit. Could we add the ability to have both scroll bars move in tandem, like: http://jsfiddle.net/j08691/5mUQH/embedded/result/. Maybe we could have a simple checkbox that enabled/disabled this functionality for those times when you don't want them synchronized.

(Here's a minor update to the above example that has the checkbox functionality I mentioned: http://jsfiddle.net/j08691/5mUQH/1/embedded/result/)

  • It's hard to keep them in tandem when they aren't the same size. If a paragraph of code is added how will you deal with it? – Servy Jul 25 '12 at 19:52
  • Simply uncheck the synchronize checkbox in the second example and they're disconnected. – j08691 Jul 25 '12 at 19:53
  • If there are significant differences it would only be useful to disconnect them (see previous reason) if there are very few differences then you're better off just going to markdown view so that all of the unchanged content can be omitted. So when would this actually be useful? – Servy Jul 25 '12 at 19:55
  • I have used IDEs that show versioned code side-by-side and scrolls it in unison, even if there is a disparaging difference in added/deleted code between the two versions. See the "Diff" feature in Netbeans for an example. It is very well implemented. – mousouchop Aug 6 '14 at 19:01

You could always switch to the markdown diffs, which wouldn't display it in code blocks and thus you wouldn't need to scroll the blocks of code at all. I personally think that the markdown view makes it much easier to find changes to code.

| improve this answer | |

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .