Editing / Preview Synchronized Scrolling
Completed
I'm not quite sure how to describe this problem, but I see it with most long documents: The synchronization between the editing window and the preview window is extremely hit and miss.
When editing I'd like to keep the line I'm editing vertically centered in the Preview window, but oftentimes the the line I'm editing is off somewhere else on the screen, or has left the visible portion of the preview window altogether.
Conversely, scrolling the preview window is usually not a good match for the editing window: whatever I'm seeing in the Preview side often results in the same content in the edit side being way off somewhere outside the visible range.
Even when I move the insertion point in the editing window, type a character, and the Preview window is supposed to jump to the same location, most of the time it ends off the bottom of the Preview window.
I haven't been able to figure out any rhyme or reason to this. There's no discernible pattern the behavior. Sometimes it sort-of works, but most often times it doesn't, and the longer and more complicated the document the greater the discrepancy between the two windows.
Is anyone else seeing this problem? I'm assuming the vertical positions of the two windows are being mis-calculated somehow. I have no idea how the logic is currently implemented, but there's clearly something not quite right. I love the concept of keeping both windows in synch, but in practice it's not working very well for me.
One other feature that would be nice, to help keep track of where I'm editing, is to somehow show the insertion point pretty prominently in the Preview window. (Obviously I wouldn't want this to show up in Print Preview in the browser, or when copying the HTML, but it would be nice to see where the insertion point is currently sitting in the preview window so I can more easily track my changes as I type.)
-
You discuss two separate things. Accuracy in one is (generally) not related to accuracy in the other. (Generally, because some of the math is shared, and if I have an error in a calculation it could affect both. But the overall logic of the two is completely different.)
1. Synchronizing while typing. This is actually relatively easy -- we know where you type, and I can use that to calculate (roughly) where the resulting text ends up in the preview. (I say roughly because doing it at the character level would require adding extra bloat to MultiMarkdown, but doing it at the word/phrase level is fast.) That said, I've been trying to smooth out a few things in the second synchronizing variant, and I can confirm some offset in at least some documents. I'll look at this, and this should be fixable.
2. Synchronizing while scrolling. This is harder. I have discussed this one at length elsewhere, but the short version is that you cannot assume a linear relationship between the editor scroll position and the preview scroll position. For example, imagine a few screens of text, followed by a series of large graphic figures, followed by a few screens of text. The images could be quite tall in the preview, but only a single line high in the editor. Over the years I have worked on some algorithms that match the editor with the preview. There will always be edge cases, but for "normal" documents it does a reasonably good job. One key exception is that if you include lots of raw HTML in your document, you will probably break synchronization. The default fallback, however, is to assume a linear relationship so you're not any worse off than you would be in other editors. With the obvious exception that if there is a bug in the calculations that will throw things off.
I'll dig back and see if there is a recently introduced error in the calculations that is throwing the results off.
0
Please sign in to leave a comment.
Comments
1 comment