Preview Pane Scrolls to Top

[pdugas]

Is there a way to keep the preview pane from scrolling to the top of the document as I'm editing content lower down?

[pdugas]

In the mean time, is there a simple way to disable the Synchronized Scrolling?

[pdugas]

I tried commenting out the calls to self.scrolledwindow_live_preview.get_vadjustment().set_value() in the scrollPreviewTo() method. As expected scrolling one panel didn't cause the other to scroll. However, when I typed into the edit panel, the preview panel scrolled all the way to the top. Makes me think the issue us not in the logic that calculated the position to scroll to but somewhere else in the stack.

[jamiemcg]

No there is no way to disable synchronized scrolling.

when I typed into the edit panel, the preview panel scrolled all the way to the top. Makes me think the issue us not in the logic that calculated the position to scroll to but somewhere else in the stack.

^ Yes that's correct. The problem is that every time a change is made, the live preview (web browser) reloads forcing the preview pane back to the top.

Trying to create a workaround, potentially changing the HTML content using JavaScript.

[SysuJayce]

It is really annoying. Everytime I edit and want to see the preview, it scrolls to the top. Please fix this as soon as possible.

[sbutcher]

this is a real showstopper for me, as i generally type with a large preview and small markdown window.
since it's a web page, would if be possible to add a #link anchor tag into the preview document whenever a new line is inserted? then you could display the web page but jump to the anchor tag instead?

[vphantom]

Maybe it's my use case, but this seems to happen a lot more in 1.87 now than it did earlier this year. What's more, stopping typing and using the mouse scroll-wheel on the edit pane succeeds immediately in scrolling the preview pane where it should be.

So, I'm thinking that maybe the scroll attempts in the preview pane are just fired too early for WebKit's liking, and a simple delay may be all it needs. We'd still be scrolled at the top while typing, but it'd correct itself after, say, 600ms of inactivity (I suspect 500ms to be the threshold).

On each keystroke, I even see the scroll handle on the preview pane "blink" to its rightful position for a fraction of a second, which further seems to me like the scrolling is simply done before WebKit forces a jump to top. Just my guess, though.

[rafaellehmkuhl]

Was this ever solved? Remarkable is the best markdown editor I've found, but this is a show stopper unfortunately :/

[vphantom]

@rafaellehmkuhl Unfortunately, right now 1.87 is still the latest version. I'd take a look under the hood, but my Python is way too basic. A work-around would likely involve injecting some attributes throughout the generated HTML in order to forcibly scroll the right one into view after each refresh. Not trivial…

[rafaellehmkuhl]

And the ideia of allowing the user to disable auto-scroll. Would that be fine?
I can take a look in the code and see if I can make anything like it.

[vphantom]

That's intriguing, but wouldn't that keep the live preview firmly at the top while we're editing though?

[rafaellehmkuhl]

I don't know. Will check the code to better answer it.