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.

[LC43]

Some insight:

The scroll up stops if i add a new line ( or a character ) at the top of the document. When I scroll down to the line i was editing and write a few words, the view sticks in line. Until I enter a new line or the line wraps. Then it scrolls up at every new character.

If i add a 2nd newline ( or, again, a character ) at the top, i can go back to the line and keep editing while the view stays fixed. rinse and repeat.

This is of course, impossible to use, but i hope it sheds some light to what its happening.

[bwu62]

Is anyone working on this issue? It's really annoying and honestly might be a dealbreaker for me. Maybe there's a way to mark the current scroll position in preview and then attempt to restore it after?

[sunbearc22]

Each time I make an amendment in the left Entry panel, the contents in the preview panel on the right will always be refreshed and re-positioned to show the first line of the Entry panel at its top. This behaviour is very annoying and makes proof reading amendments very inefficient, especially for amendment of very lengthy markdown documents. Whenever the preview screen has to refresh, it is best that only the amendment is reflected without adjusting the display position of the contents in the preview panel. Hope you can fix this else I think it can be a "show stopper". Thank you.

[sunbearc22]

I also noticed the alignment of content in the left Entry panel and the right Preview panel can be quite off, i.e. they can be quite misaligned. Hope this issue can be fixed also. Thank you.

$ remarkable --version
*Spellchecking not enabled.
*To enable spellchecking install pygtkspellcheck
*https://pypi.python.org/pypi/pygtkspellcheck/
remarkable 1.87

$ uname -rs
Linux 4.10.0-42-generic

[kb173]

I looked into this a bit - might it be related to what's described here?
It seems to me like scrollPreviewTo(self, widget) is trying to set the correct value after updating. So I tried inserting this before setting the scroll value in scrollPreviewTo(self, widget):

# Resolve all pending events
while Gtk.events_pending():
    Gtk.main_iteration_do(False)

It did seem to make it better, though it's hard to tell since the behavior is inconsistent. There was also still a short jump to the top inbetween. Sadly, it also resulted in crashes:

GtkSourceView:ERROR:gtksourcecontextengine.c:1527:find_insertion_place: assertion failed: (segment->start_at <= offset && segment->end_at >= offset)
Aborted (core dumped)

[jlusiardi]

I experience this issue as well. The document I am working on includes some slower loading badges (travis ci, coveralls.io and gitter). Removing them makes the situation somewhat better. But perhaps scrolling should not be done until the content was completly loaded? And if rendering takes to long, could it be put into an extra thread?

[DarthThomas]

I encountered the same issue. Please help :(
I got this

Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.

[1049451037]

Sorry to offend...but this bug is really annoying...

[erm3nda]

This bug turned out into a "no use" for me :-/ so i think is really important to fix it.

[ployt0]

There is a work around I discovered, simply scrolling (at first with mouse wheel but I believe with paging too) the left hand side brings the right into sync again.

[resotek]

I'm experiencing the same problem. The preview pane scrolls to the top when I type in the markdown pane. Remarkable 1.87, Linux Mint 19.1 Tessa (Ubuntu 18.04).

[ciri]

A super sloppy hack that I use for this is to include the following JavaScript code at the bottom:

<script> window.scroll(0,200000) </script>

This will cause the window to scroll down at all times, which is quite helpful in your initial writing ... You can vary on this theme to get it to scroll to the middle, etc. Note: this only works when it is placed at the end of the document.

[lowlevel-1989]

Fix #380

[Cybernetic1]

<script> window.scroll(0,200000) </script>

This trick seems not working for me (nothing happens after I go past the bottom), but I am using the version after bug fix #380. Maybe that's the reason?

[Bat1963]

Just start typing again and the review panel goes back to where you are typing, right?

[fdutheil]

Review panel seems to live its own life and not being bothered where the edited text is located (but is still dynamically updated if markdown edited is visible beforehand).
Having to manually manage & scroll the preview pane is a major deal breaker.

(context: gentoo using app-editors/remarkable-1.9.0_pre20210320-r3 & python 3.12 & x11-libs/gtksourceview-3.24.11-r1)