Scrolling not in sync / showing correct part of file between frames

[sammcj]

I've noticed that when scrolling the Markdown and Rendered panes are not in sync, so you can be in completely different places in the same file on each window.

[sammcj]

Ok I just saw #4 and this appears to be deliberate, which seems pretty strange to me.

Is it possible to at least add an option to keep them in sync?

[ross-w]

The problem I have is what @tmikaeld said on #4 - that although the scrollbars are in sync the content is not. So when you have images or large headings the actual content is below where the scrollbars automatically sync to.

[sammcj]

Thanks @ross-w that's what I was trying to say.

[tmikaeld]

The app "Marked" solves this by scrolling to the area that are getting changed, i think it's at least a part way solution.

[uranusjr]

Haven’t tried Marked yet, but to achieve what @tmikaeld described we at least need to know how coordinates the source and rendered results map to each other. I don’t think this is currently possible—Hoedown has plans (hoedown/hoedown#22) about providing a source map, which should provide means to achieve it (not sure), but nothing is concrete yet.

As I said in #4, I would be interested in making true scrollbar syncing. It’s just not feasible to do it now.

[tmikaeld]

Maybe we don't need to, the rendered result is html and thus every change will produce a new node in the DOM and when that node pops we can scroll to it?

[uranusjr]

Then we’ll need to parse the whole DOM tree (or at least up to where changes happen) every time the HTML is updated, which I suspect would kill performance. But I’ll try to evaluate that. Haven’t though of that.

[tmikaeld]

Iterating over the DOM nodes is very fast, it should work fine as long as we don't change the tree.

[timecode]

For anyone needing the left and right panes to sync before this issue gets looked at (it seems to be worse when the document gets large, by the way), there's always the interim measure of adding whitespace (many newlines) temporarily in the markdown pane (at certain points). That way, at certain points in the scroll, the panes sync up. I've been adding space just before heading levels, # and ## usually, so that a long document is able to be edited with the preview next to it - otherwise it's off the pane and not much use :-/
The whitespace can simply be removed once editing has been completed.
It's a pretty weird thing to have to do, but it works if you still like using MacDown (I do).

[bac]

If the two panes cannot be made to be in sync properly, then they should be unlocked to scroll independently. Currently the two are out of sync, yet making a change in the editor causes the render pane to scroll wildly to another location. So it requires lots of scrolling to find the rendered and then the position gets lost as soon as a change is made. Maddening. (But other than that I found macdown quite nice on first use. Thanks.)

[uranusjr]

You can disable syncing in the preferences.

[jkwill87]

I cannot scroll properly (sometimes at all) in the editor pane regardless of whether syncing is enabled or not. The only way I can scroll properly in editor pane properly is by disabling the preview pane altogether.

[unliu]

@uranusjr after disable syncing it needs even more scrolling to find the newly rendered content, as the right pane will automatically scroll to the top every time I type a letter (auto update mode) or press Command + R.

Is it possible to keep the right pane "fixed"(find out the first visible element and keep it's position fixed) when refreshing? That might helps a lot.

[uranusjr]

@unliu It’s reasonable. Could you open a separate issue for this? 😃

[unliu]

@uranusjr sure:)