8

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/)

Improve this question
4
  • 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
    Commented Jul 25, 2012 at 19:52
  • Simply uncheck the synchronize checkbox in the second example and they're disconnected.
    – j08691
    Commented Jul 25, 2012 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
    Commented Jul 25, 2012 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
    Commented Aug 6, 2014 at 19:01

1 Answer 1

Reset to default
1

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 .