Sync the position of edit window and preview window

[mitya57]

I am using ReText version 4.1.0 but I still have the bug reported here:
https://sourceforge.net/p/retext/tickets/14/

Also I think it would be very convenient for the user if the position of the edit window and the preview window are in sync, no matter in which window the user scrolls.

Reported by: spacetimewave

Original Ticket: retext/tickets/108

[mitya57]

• labels: --> feature-request

Original comment by: spacetimewave

[mitya57]

Again, ideas on how to implement proper sync are welcome. For now the algoritm is "distance to bottom is preserved".

Original comment by: mandriver

[mitya57]

I don't know so much about Qt (actually I found your project is so useful to me that I am learning pyside now and wish one day I could contribute or fork it), so I don't know where the difficulty is. Intuitively I would say: when one scrolls one area, get the scroll position of it, and set the scroll position of the other area as the same value. The position can be defined as the absolution position / maximum length. Will this work?

Original comment by: spacetimewave

[mitya57]

No, this won't work. User may have embedded images, videos, documents, etc, for which the preview fragment takes a lot more space than the source.

And vice-versa, some HTML markup (i.e. stylesheets) take space in edit area but not in preview area.

Original comment by: mandriver

[mitya57]

Then what about this? When scroll, we find out how many paragraphs (or characters) are scrolled up/down, and make sure the same amount is scrolled up/down in the other area.

Another idea is a little bit complicated. Ok I will use an example. If we just open the document and scroll down we first check what is the last line (or last few words) at the bottom, then we start search this line of content from the last line of the other area before scroll and the first match should be shown at the bottom of the other area too. As we do this continuously, I think the first march should be found quick enough the we don't see any lag.

Original comment by: spacetimewave

[mitya57]

That also won't work. If you search for one word of the string, then it'll most likely be found in many places. If you search for the whole line, than it'll in half cases not be found at all (any formatting like will break it, like bold/italics text, lists, headers etc). Anything more complicated will be too slow.

In any case, if you manage to replace the current updatePreviewBox() code in window.py with something better, it will be accepted.

Original comment by: mandriver

[mitya57]

How do Mou and Lightpaper handle it?

There's also this clever idea, which would be interesting to steal: make the entire page the preview and only render the lines under preview as text. This would probably require custom Qt widgets and be tricky to get the markdown parsing right, but the effect would pay off a thousandfold if you could do it.
(sorry I'm not logged in. I forget my sf password)

Original comment by: *anonymous

[mitya57]

There are lots of other editors with combined editor & preview. ReText uses a different logic, and it is not possible to get such behaviour.

I will welcome the contributions if someone wants to rewrite the logic, though.

Original comment by: mandriver

[mitya57]

Guess Qute (a cross platform Qt md editor) also behaves like the one the previous poster mentioned. You can see its behaviour in its web site.

Original comment by: gooddead

[mitya57]

how about inserting anchors in the preview and updating the preview with an anchor link closest to the current line position.

it would clutter the html, but it would only be required during live preview, so who cares.

an anchor per source line for example. "<a id="retext_line128" />"

Original comment by: *anonymous

[mitya57]

That isn't possible with the current code logic. Neither Markdown nor reStructuredText document trees have any information about lines. Even more, ReText doesn't wark directly with markups, it uses a wrapper for that (pymarkups).

Original comment by: mandriver

[Griffon26]

I am going to take another look at this and my earlier implementation for it.

Dmitry, are you fundamentally opposed to the additional HTML markers? Having HTML elements in the webkit view and knowing which part of the markdown they are associated with is the only way I can think of of making this work. Could you clarify your objections so I can think of a solution that would be acceptable?

[mitya57]

How are you going to implement the markers? I would like to avoid ugly hacks like searching for the text in the HTML. If it is a clean Markdown extension that adds some undisplayed HTML nodes then it's probably fine.

[mitya57]

This is now fixed in master, thanks to the awesome implementation by @Griffon26.