[Feature request] Better synchronized scrolling in desktop app

When editing clipped notes, the side-by-side windows cannot be scrolled independently. This often means that due to images (which take up maybe two lines in the source side, but the equivalent of dozens in the render side), I often cannot see what I’m editing while I’m editing it, and need to scroll and up and several times.

I understand that accounting for image size might be a non-trivial problem, but that would be the ideal.

At the very least, guaranteeing wherever the cursor is in the left window would still be visible in the right window.

If it would be an easier solution, it would be a nice temporary workaround if scrolling the windows operated as it does now, but the render-side scrollbar can change the scrolling offset. (In other words, scrolling the left side scrolls both windows, but scrolling the right side only scrolls the right side.)

1 Like

That won’t be fixed without changing the Markdown lib: https://github.com/markdown-it/markdown-it/issues/336#issuecomment-282566698

And while other Markdown libs might not have this issue, they will most likely have other different issues so there’s no plan to switch.

1 Like

What about a checkbox in the settings to “decouple” the two so we could manually scroll the preview window to the section we’re editing? Thank you for all the hard work!

1 Like

Any idea if this is still a possiblity to have in Joplin?

To have seperate scrolling for editing section and render section?

@laurent would you accept a PR for this?

I think so but can it be implemented though? Because markdown-it only keeps a line map, while to support proper scrolling I think we’d need a character map?

I should have been more clear, I was referring to the ability to completely disconnected the scrolling between viewer and editor.

That said, I I believe it's possible to have sync scrolling with only a line map. I had started working on it about a year ago but put it down for higher priority work.
The basic scrolling mechanism would be the same (using percent scrolled) but would use the percent scrolled between lines in the line map. From my testing this was never out of sync for more than a couple pixels.


I believe it's possible to have sync scrolling with only a line map. I had started working on it about a year ago but put it down for higher priority work.
The basic scrolling mechanism would be the same (using percent scrolled) but would use the percent scrolled between lines in the line map. From my testing this was never out of sync for more than a couple pixels.

As far as I know, this is what VS Code does, and it works great (in most cases). Actually, it is one of the main reasons I access Joplin notes via the VS Code plugin. As CalebJohn said, this method uses the percent-based linear interpolation between the top pixels of adjacent markdown line tokens. In my opinion, this method is strictly better than the current approach in Joplin, because Joplin, after all, uses the same method but only with the topmost and the bottommost scroll position of a given note.

For example, both methods may fail to precisely sync extremely long paragraphs (or code blocks, html blocks, etc.) due to the absence of the character-level source map. However, if there are a lot of such long paragraphs, in Joplin the error in the scroll position accumulates and the source and html will be completely out of sync, while in VS Code the exact sync between the two panels are guaranteed at the start of each paragraph (or at the start of each line token).


A pull request for line based scrolling I wouldn't mind, but I guess it's quite tricky to implement. An option to disconnect the scrolling however I'm not too keen on it as I think it's quite a niche feature, which would become unnecessary if scroll by line is ever implemented. Even the Rich Mardown plugin makes this not so needed because it's possible to do a lot just from the editor.


The problem occurs when the text you're editing is out of rendering window, so you can't really see in real time what you're editing. Atleast it's not consistent at times, especially when you have a really long file.

Rich Markdown is a nice way of approaching this, however it has it's limitations when you're trying to work with plugins or your own html.

A simple option and workaround for now would be an option to select whether you would like synchronized scrolling or not.


Yeah... while I do believe the sync scrolling has much improved since I started using Joplin way back when, I still find it to be a weakness, at least the way that I use it... I take screenshots to go with my notes and quite a lot of them... I often find that I'm editing where I can't see it in the rendered view and find it frustrating. I understand this might be a niche thing, and might not make sense to spend the effort/time because of the amount of changes required (markdown lib change or not having a character map, etc.) to get it 100% accurate, so my vote would still be for a simple option to turn off the synchronized scrolling. Assuming this of course would also not be much of an effort to implement. Thanks again for all the continued work and effort!

EDIT01: Actually, it just occurred to me, the answer to this might just be a plugin! One that gives you a button in the upper, right corner next to the Toggle Editor Layout button. Don't have the skills to code something like that, but maybe someone would take this on...

1 Like

@CalebJohn, I applied your old sync-scroll implementation to the latest version (v2.4.5), and it looks working well. It does not perfectly synchronize but looks enough practical. What problems were there?

If i remember right, it only performed syncing in one direction (editor -> viewer not viewer-> editor). I think it also wasn't as efficient as I wanted. I had a number of stress testing notes, and i believe it was failing on some of them, i think there were a couple of small bugs with my implementation.

Thanks for your reply.

Sure. I hadn't noticed it.

Which is a major problem, CPU efficiency or sync precision?

Both have an acceptable threshold. I would say that currently the sync precision in Joplin is not acceptable (although not a deal breaker for using Joplin). The problem is that if the sync precision isn't improvemed properly, it can make Joplin unusable for people with lower end computers.

In the meantime before/if anything gets implemented in this vein, it might be worth people noting you can use HTML tags in notes so you can hide stuff from the viewer with < details > tags (you can then add details of what's hidden with < summary > tags inside them)

I've found this feature pretty useful since I use Joplin to keep a work diary with days of the month as headers, adding a table of contents would add a LOT of lines to the top of a note so I hide all of that with the following:
< details >< summary >TOC</ summary >


</ details >
Then I can access my TOC by clicking the box but if it's closed, the text stays synced!

(Note: spaces are added in tags to prevent this website from processing them...)


Thanks for your information.

I finished implementing the initial version of a sync-scroll feature based on your branch. The implementation is here. It's the branch of Joplin v2.4.6 and ready to use.

The following features are added.

  • Bi-directional sync-scroll (viewer <-> editor)
  • Performance improvements:
    • The mapping between line and scroll position is cached.
    • Fast mapping queries by using binary search.
  • Some cleanups.

@CalebJohn, before I send its pull request, I want some opinions from you. Could you collaborate with me? If you are OK, where is an appropriate place to discuss?

  1. In this topic.
  2. A new github issue or any existing one
  3. Anyway, pull request first.

This is great! I'd be happy to help in any way i can.

You can create a PR and we'll discuss there. It's always easier to discuss with the code right there.

Thank you. I'll prepare a PR.


@ken1kob I've been playing around with your branch, it's really awesome! It feels great to be able to scroll through a huge not and still have everything lined up correctly.

One issue I did have is that Cutting/Pasting large chunks of text will result in the scroll being out of sync, I think this is because the scroll map doesn't get regenerated soon enough. It should be possible to manually initialize a scroll or delay the scroll until the map is ready.

I'm looking forward to the PR!

1 Like