sync the scroll position

[jarvisniu]

sync the scroll position of preview with the source.

[philippe-git]

Thanks for proposing sync scrolling!

I'd like to address your PR by summarizing the train of thoughts I had just before choosing a related feature over sync scrolling. This decision goes back to 2013 (658fd0c0c34a4f47d2c4198bc68bb21a5734a6da), when the editor had just been created, and any amount of scrolling still had to be done by hand.

Train of thoughts:

1. There are two pain points to address in this first version of the editor when working with long documents:
   1. Scrolling to the bottom of the preview panel when writing: this should be done automatically
   2. Making the preview panel display the part of the document of which source is displayed in the preview panel (i.e., sync scrolling): this should also be done automatically
2. Solving pain point 1 is easy.
3. On to pain point 2. There's one solution that can solve pain point 2 perfectly. Unfortunately, this solution requires some sort of WYSIWYG editor in the preview panel rather than a simple textarea to be able to map HTML elements to their Markdown counterpart. I imagine another, more convoluted solution, would be to hook into a Markdown parser to create such a mapping at parse time. That seemed overkill for such a feature (and still does).
4. There's no solution I can think of that can solve pain point 2 perfectly.
5. Oh, there's a simpler solution that can solve pain point 2, although not perfectly. How about making the preview panel automatically scroll proportionately as much as the source panel (the solution you're proposing here)? This solution will work very good in most cases, which is fantastic, but can totally fail if some of the previewed content takes up disproportionate space compared to its source (e.g., a large image).
6. Since there's no perfect solution to pain point 2, and I don't think it's a deal breaker, let's leave it as is. And let's solve pain point 1 by automatically scrolling to the bottom of the preview pane whenever it changes. And let's put that feature behind a toggle, so that it doesn't bite us when we're editing the top of a long document.

And that's where things have been left, with pain point 2 remaining unaddressed.

So I'm glad you're bringing this issue back up! I'm still not sold on the idea of implementing a partly-flawed solution, but I've come to think sync scrolling has to see the light, one way or another.

I'd like to take some time to think it over, and try sync scrolling with various documents to see how it fares. I'll comment here when I've made up my mind.

Feel free to continue the discussion here in the meantime, and thanks again for your contribution!

[jarvisniu]

Thanks for such a detailed reply!

But I still think we should add the sync scrolling with this simple solution: automatically scroll proportionately. Here is my reason:

Assume that we choose the convoluted hook method and we made it! But we still can't solve it perfectly. The most we can do is to make only a little part of the preview (such as a heading) at the same position with its source code. As for the rest parts on the screen, we can't make them sync perfectly meanwhile. Because their height is unequal! So, there is no perfect solution to solve this problem ... except for the WYSIWYG editor.

But in WYSIWYG editor (like Microsoft Word), we don't need to split the screen into two panel. We just need one, because the source and the preview are the same.

You can have a look at this editor: http://25.io/mou/. Its source code container isn't a simple textarea. Each line in the source code can resize itself as you change it. But it still didn't solve this problem so perfectly as you think. After try it, It just use this imperfect proportionately scrolling.

So, before we change this screen-division method to WYSIWYG, we don't need and can't to make it so perfectly.

As you said, this solution will work very good in most cases. The bad cases, to be specific, is that when I scroll the source into my view (mostly the vertical center position), the corresponding preview is not appear in the screen. But I think it's not far from there. At this time, what I need to do is just scroll a little more. It does not bother at all. I don't even need to move my cursor.

But without this sync scrolling, it will a little bother. For me and many other people, changing is more common than appending. So when I was changing, I have to toggle off the scrolling and scroll the preview manually every time. This is painful comparing with just a little more scrolling in the original cursor position.

[philippe-git]

v3.1.0 has been released, and it includes your contribution – thanks!

I'm glad "proportional" sync-scrolling is finally there, and am looking forward to implementing "perfect" sync-scrolling in the future.

To be clear, to me, "perfect" sync-scrolling = perfectly aligning a reference point in the preview panel with the same reference point in the source panel. This screencast is a great example of that. That reference point could be the top of the visible area (like StackEdit does), or the caret position, or something else – I'll see what works best.

Technically, "perfect" sync-scrolling means mapping both panels of the editor. As of this release, the preview panel is already mapped, but the source isn't: it's a simple textarea, hence a "mirror" div is required to wrap elements around lines and map those elements. (The presence of HTML elements is what I meant by "some sort of WYSIWYG editor", which was a misnomer.)

In the meantime, since "proportional" sync-scrolling has several pitfalls, that release also includes additional mechanisms to ensure that the area currently being edited is always visible in the preview. Here's a before/after to illustrate how it works.

Before:

After:

Both the web app and the Chrome app are up to date, so you can give them a try right away. Enjoy, and feel free to share any feedback on this feature here.