Auto-scroll live preview

[mitya57]

When I am using live preview (Ctrl + L) while editing long document, every time preview refreshes, it scrolls automatically to the top. This means when I am in the middle or at the end of the document (typical use-case), I keep seeing preview of the beginning of the document, while I would like to see the preview of what I am currently typing.

ReText should scroll preview pane to the same place where cursor is in the edit pane.

Reported by: nurkiewicz

Original Ticket: retext/tickets/52

[mitya57]

This was fixed in 3.1.1, are you using an older version? If you use Ubuntu, I've just updated my PPA with the latest release.

Original comment by: mandriver

[mitya57]

Indeed I was using 3.1.0 in Ubuntu via PPA. Now I got 3.1.2 and I see some difference. However live preview is still not scrolling to the place where I am typing, it just stays at the same place where it was previously (as opposed to moving to the very top).

This doesn't work very well when writing a long document as I constantly have to scroll down the live preview. I understand it might be challenging to discover the place live preview should be moved. I think scroll to bottom checkbox somewhere would be enough.

Original comment by: nurkiewicz

[mitya57]

Fixed in Git. Now, when you edit long documents and the preview box is at its bottom, it will keep being there when you type more text.

Notes:

• You should still scroll the preview box first time (to suit cases when one wants to always preview the top of the text);
• This won't work with WebKit engine :(.

---

• labels: --> fixed-in-git
• status: open --> accepted
• milestone: retext-next --> 4.0

Original comment by: mandriver

[mitya57]

• status: accepted --> closed

Original comment by: mandriver

[mitya57]

Fixed in 4.0.

Original comment by: mandriver

[mitya57]

Either this is not working or I haven't been able to configure it. I'm using version 4.0.1 on Ubuntu.

Original comment by: legendario

[mitya57]

• status: closed --> open

Original comment by: legendario

[mitya57]

Thanks for testing. Let me describe how things currently work, and please let me know you get something different:

1. When you scroll the preview pane to some point, then modify the text, the preview pane scrolls to the position having the same distance to bottom as its previous state.
2. That doesn't work with WebKit. In WebKit, there is only a "stick to bottom" behavior implemented (I don't remember why I didn't add WebKit support: the QtWebKit API was not working properly?).
3. There is no guarantee that text in preview pane will match text in editor pane: these texts have nothing in common (from ReText's point of view) and it's impossible to do any matchings in a not markup-specific way).

Original comment by: mandriver

[mitya57]

Still not work for me. Editing the document does nothing to the preview pane.

Original comment by: legendario

[mitya57]

I can attest to the fact that the Live Preview pane does not match the Edit pane.

Maybe instead of making the preview pane follow the edit line, the preview pane's scroll bar could mimick the position of the scroll bar position of the edit pane e.g when you scroll the edit pane the preview pane scrolls aswell.

Original comment by: *anonymous

[mitya57]

If you used documents with math formulas, things should be better in the current Git snapshot.

Original comment by: mandriver

[mitya57]

Same problem here: it would be nice if edit pane and preview pane were aligned

Original comment by: *anonymous

[mitya57]

I have tried Ubuntu v4.1.0 same isue, I think it is not fair just to tell it is not working, I think following is the pseudo how how it should work.

• After pressing key check following
• Locate last character on the visible screen
• Determine vertical location (height in .px) of the line of the last character
• Find same character in the Preview panel
• Set location of the Preview panel to the edited line location ...

And you can choose to anchor on bottom or top of the side by side lines.
Even when you are using smaller font in this way you will have discrepancy of just a few pixels.

I can offer my self to make this patch but can you at least point me to the line of code where this has been done previously?

Original comment by: *anonymous

[mitya57]

It is practically impossible to find the line being edited in the preview box, because the lines usually don’t match (i.e. the inline syntax gets applied).

Patches welcome, of course. Take a look at updatePreviewBox method of ReTextWindow to see how that is currently implemented.

Original comment by: mandriver

[mitya57]

I would suggest that the automatic updating of the preview pane would be made optional and additional there would be a way to update it on demand. Because sometimes it is tiring to have the preview pane constantly flickering - in case you are constantly typing. Or is there already way?

Original comment by: *anonymous

[mitya57]

Actually, I don't see why that is needed — if you don't need the preview pane, just hide it and then show again when you want to see the preview.

But feel free to propose the design (i.e. how will one trigger the update) in a separate bug report.

Original comment by: mandriver

[mitya57]

I am using version 5.0.0-1~14.04 from the Ubuntu PPA. When I scroll to the bottom of the edit window and type, the preview still shows the top of the document. When I try to scroll to to bottom of the preview and click back to the edit window then the preview jumps to the top again. Functionality that was working earlier (4.x?) is not working now.

As a suggestion, perhaps you could try to just be sticky? When the edit window is at the top, stick the preview to the top. When at the bottom, stick the preview to the bottom. When anywhere else, let the previous scroll position of the preview be retained.

I work with images in my markdown. They can make the scroll bars not line up at all and I can see how other formatting tricks can make the preview text not align properly with the output.

As a potential solution, can you modify the text in transit? Soemthing like this?

1. Get edit text and cursor positon.
2. Add some marker, perhaps <!-- RETEXT MARKER HERE --> where the cursor was found. Or maybe pick an unused Unicode character?
3. Convert to HTML.
4. Find comment element or the Unicode character and scroll the best you can to put the comment in the middle of the preview pane.
5. If using a Unicode character, remove it?

You may have issues with being inside code fences, in the middle of multi-character markup sequences and other things. Maybe the marker could be added at the beginning or end of a line?

Original comment by: fidian

[mitya57]

Hi, unfortunately I do not like this approach.

• It is a hack, and will require patching PyMarkups library and/or individual markups.
• I can't place Unicode characters. If user wants to copy-paste text, it should not contain garbage.
• HTML tags won't work with markups that don't accept raw HTML (like safe-mode Markdown or reStructuredText).

I think the current behaviour is good enough (the scrolling position is remembered, i.e. if the preview area was on bottom, it will stay on bottom). However patches that will improve it are always welcome :)

P.S. There aren't any differences in preview handling between 4.1 and 5.0.

Original comment by: mandriver

[mitya57]

Let's continue the discussion in #108.