Viewer and editor panes are not in sync with Code Mirror

[laurent22]

There's a large white space at the bottom of the Code Mirror editor, which in general is good for editing but in this case it means the editor and viewer are out of sync. So I think the bottom gap should either be made smaller or the same gap should be added to the viewer.

Before

After

[laurent22]

@CalebJohn, any idea on how to fix this?

[CalebJohn]

@laurent22 yes I can change this. But I don't really see the issue with the current behavior. Is it just the it seems more comfortable if they both scroll past the end the same amount?
To me it makes sense that you wouldn't want the viewer to scroll past the end because this maximizes what the user can see rendered.

That said I do think one full window of scroll past end is excessive, I'll look into reducing that and I'll look into adding scroll past end to the viewer, even though I think the current behavior is better in regards to the viewer.

[laurent22]

But I don't really see the issue with the current behavior. Is it just the it seems more comfortable if they both scroll past the end the same amount?

It's less of a problem with very long notes than with smaller ones. When a large part of the note is a blank space, then the editor and viewer are definitely not in sync.

For example in the second gif, at some point I scroll to the bottom of the viewer, yet the editor is still somewhere at the top of the note. For sure we'll get bug reports regularly about this.

[CalebJohn]

If you scroll to the bottom of the viewer then you will also scroll to the bottom of the note contents. In your gif this seems to be working perfectly to me. Actually since your example note doesn't have any image or inline math, the lines stay almost side by side which I think is pretty good!

That's a fair point, I definitely don't want to have to defend the behaviour on the forum everyday...
The expected behavior would be to have a matching scroll-past-end on the WebView?

[laurent22]

Hmm, that's true the two panes content actually match, and it seems similar to the previous content. But the fact that the two scrollbars aren't in sync seem a bit strange, like it looks like there's something past the end of the editor, when there isn't.

For sure having a gap at the bottom of the editor is good. Should the gap be mirrored in the viewer, I'm not sure now.

[CalebJohn]

I can look into having the scrollbars reflect eachother more accurately. I think it's possible in codemirror to take complete control of the scrollbar, but it will involve us making a fake scrollbar and controlling it at all times.

An alternative is to reduce the size of the overscroll, this will make the difference less of an issue.

[vsimkus]

I feel like the scroll sync is not great in the current editor either and could be an overall improvement. Currently the views often go out of sync with documents containing table of contents ([toc]), tables, larger images or katex equations. This cannot be solved directly if you just synchronise the two views based on the scrollbar position.

I feel like it would be much more consistent if Joplin took the VSCode markdown preview synchronisation approach, where the two views are synchronised based on the top lines in the two views - in particular, the tops are always aligned. @CalebJohn Do you think it's something that could be done on Code Mirror?

Alternatively, and that's not quite relevant in this thread, it could allow switching the synchronisation off as an option.

I find that in many of my notes the preview and the editor are completely unaligned to the point where the split-view is unusable.

[CalebJohn]

@vsimkus I've actually been looking into updating the scroll behaviour (to do as you describe) using something like https://github.com/tylingsoft/markdown-it-source-map#markdown-it-source-map. Which would work on the codemirror editor or aceeditor.

And actually if we could get this working nicely we can simply hide the editor scrollbar because the content will be in perfect sync. That way the overscroll won't affect the scrollbar positioning. What do you think about that approach @laurent22 ? I imagine there might be some challenges with things like TOC, but we'll have to see.

[laurent22]

I've looked at this type of scrolling before and it has some advantages, but the problem especially with markdown-it is that the source map is only at the line level markdown-it/markdown-it#336, so I think it won't work so well in some cases like images or long paragraph (which is just one line in Markdown).

We also need to take into account complicated content in Joplin, imported from other programs or from the clipper, like huge block of HTML, tables within tables, CSS that moves things, etc. A note can even be one long line of HTML. Still might be worth a try though.

For the scrollbar, perhaps the solution would be to have just one scrollbar for the two panes - if syncing between panes is working as it should, the scrollbar position should anyway be the same, so only one in the middle would be enough. I don't think we should implement our own scrollbar though, it feels like too much trouble for something that's normally built-in.

[CalebJohn]

This markdown-it demo has the syncing fairly close. it doesn't appear to support complicated inline html so it's not clear how good we can do. But I have a degree of confidence that we can copy their implementation and get good results.

[ghost]

Tall multi-line latex equations seem to be the out-of-sync even worse, for example using aligned, integrals, sums:

$$
\begin{aligned}
    z
    &
    =
    \sum_k a_k
    \\
    &
    \approx
    \int_0^1 a(x) d x
\end{aligned}
$$

[abrac]

I always scroll with my keyboard (i.e. by moving the cursor, rather than scrolling the mouse-wheel).

I therefore prefer a sync behaviour similar to the MarkDownPreview for Vim plugin. Their viewer always ensures that the text under the cursor is visible in the editor.

Here's a GIF below of its functionality:

If you look carefully, the text under the cursor is more-or-less centered in the viewer. It is always visible.

However, with CodeMirror, the line I am editing is sometimes not visible in the viewer, unless I scroll with my mouse. See the image below:

I would need to scroll down in the viewer with my mouse in order to see the changes I am making in the current line in the editor.

I hope my request/issue is a reasonable one. I'm not sure if you would prefer me to raise this in a separate issue...?

[FischLu]

I have the same problem, if there are images in the note, then the viewer and editor are not synchronized.

[CalebJohn]

For anyone that comes upon this issue in the future. It was tracking a specific issue where there was padding at the bottom of the editor, but the viewer had no such padding.

The issue mentioned by other users pertaining to images and math causes the viewer to become out of sync still exists, but please don't bump this issue because. #2242 is a better issue to reference. Please leave a thumbs up on the top comment of #2242 if you would like the scrolling to be in better sync.