live preview window won't stay in sync with editor window

[Steven Samuel Cole]

I am working on a markdown document that is so long that it can not be fully displayed in either the editor to the left nor in the live preview to the right without scrolling. When I edit text at the beginning of the document, the live preview won't keep showing the part I am working on, but instead 'jumps' to a document part further down; seemingly first to somewhere in the middle, then towards the end of the document. When I scroll the live preview back up and go on editing, the preview jumps back down.

This behavior is not only annoying, it actually makes the live preview pretty much useless - unless you're working on the end of the document.

This is version ReText 4.1.0 installed from Kubuntu package 4.1.0-1 on Kubuntu 13.10 64 bit. Happy to provide more context info if that helps.

[Dmitry Shachnev (mitya57)]

Thanks for the bug report. This is a known issue, but it's difficult to fix it.

The current behaviour is that "distance to document bottom" is always preserved. Do you have any suggestions on what the algorithm should be?

[Steven Samuel Cole (steven-samuel-cole)]

Thanks for your info! :-)

Ideally, the live preview should show the same document section as the editor window. If that location is a little off, that's cool, I've seen that in other editors as well. Scrolling a little sometimes is acceptable, but the way it is now, I have to scroll all the way back up whenever I press any key and being that, I would not use the live preview at all - which IMO would be a *massive*loss of functionality.

Algorithm-wise, the document has a total number of lines n and the editor window can display a number of lines m, ranging from line number a to b. Editing takes place in the line with the cursor, x. See attached sketch.
There are corresponding numbers in the live preview, but as opposed to the editor, lines may have different heights and there might be images. There is no cursor in the preview, but x denotes the location that should always be visible while editing: The user moves the cursor through the editor and expects the preview to follow.

The numeric relationships between n, m, a, b and x should roughly stay in sync for both sides. In the live preview, these relationships would ideally be calculated on a pixel basis, but I don't know if there is a simply way to determine the pixel-wise height of each line in the preview. You might get away with just counting lines in there, as well.

As a later step, the live preview should also move in sync with the editor if the user scrolls using the vertical scroll bar or a swiping gesture. The cursor might then be located outside the editing window.

Just my 2 cents.

[Christoph Buchner (bilderbuchi)]

For me, the live preview jumps to the top of the document pretty often, I think on every save. Is that the same bug?

[Dmitry Shachnev (mitya57)]

@Steven: Unfortunately, the markup can do *anything* to the text (like: inline markup, images, embedding other documents, ignore some commented out lines), so it is *impossible* to match the source and HTML lines. Also, the percent values of scroll positions should not be equal, because of the same thing (they can differ a lot in both directions).

@Cristoph: Do you really believe it gets reset *on saving*? In my test saving has no impact on live preview position.

[Benedikt Naessens (benenaes)]

I didn't go through the code. One question: do you create and render the text completely from scratch each time ? Maybe you can do a diff between the old and new one each time and jump to the section closest to the first changed location ?

[Dmitry Shachnev (mitya57)]

Yes, I do it from scratch. Of course, I can get the diff, but there is usually no way to "jump" to the location given only its HTML code.

[Adrian (adrian-rosian)]

maybe you can jump to the end of the body html node where the contento of the node without markup is the most similar to the currently edited markdown paragraph. Does that make sense?

[Dmitry Shachnev (mitya57)]

@Adrian: please explain what you mean by "the most similar". I am *not* going to do statistical analysis of the text every time you change the text.

P.S. Patches welcome, as well as the suggestion of a fast algorithm to jump to the right place.

[Ｖ字龍(Vdragon) (vdragon)]

Hi, GitBook Editor seems to support this feature, I wonder if it's legacy version(which is open-sourced on GitHub) have the implementation?