preview jumps back to top

[normoes]

Description

• Having the asciidoc-preview tab open, I tend to switch a lot between the preview tab and the editing of the README.asciidoc tab - saving, and watching the immediate change in the preview tab - I like that.

• Provided I am in the middle of my long asciidoc preview:

  • Since the upgrade to the new version (Unfortunately I don't know what previous versions I was using, I didn't upgrade for a long time, I think) the preview jumps back to the top when I click back into the README.asciidoc tab.
  • I reproduce it by scrolling within the preview tab to somewhere in the middle and then switch tabs by clicking into the editing field. So from the preview tab to the README.asciidoc tab and back again. Sometimes this needs to be done more than once. Sometimes it jumps to the top, sometimes somewhere else and sometimes nothing happens at all.

• Atom version: 1.17.0 x64

• OS: Linux Mint LXDE Linux "hostname" 3.19.0-80-generic #88~14.04.1-Ubuntu SMP Fri Jan 13 14:54:07 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

• asciidoc-preview version: 2.10.1

• language-asciidoc version: 1.10.0

[normoes]

I just observed the following reproducible behaviour:

• README.asciidoc on the left tab and preview on the right tab
• Within the README.asciidoc tab
  • Holding down the left mouse button and moving the mouse up and down (marking several lines) scrolls the preview tab.

Maybe there is connection.

[mojavelinux]

I reproduce it by scrolling within the preview tab to somewhere in the middle and then switch tabs by clicking into the editing field.

You are experiencing the new scroll sync behavior. It syncs the preview to the location of the cursor in the editor. Assuming it's not making any mistakes (which is a possibility), this behavior is expected. You can disable it though in the settings.

[normoes]

Thanks for the reply. Ok, that explains the behaviour I described in the first comment.

The original problem remains (with the scroll sync option active).

For now, I switched it off. Thank you for the tip.

[mojavelinux]

There are still some nodes that aren't mapped correctly, so it could be that it's jumping to the top because it doesn't know where to go. This is still an experimental feature, so we are looking for those types of cases.

[normoes]

Do you need more information then? I am willing to help :+1:

[mojavelinux]

Yes, that would be fantastic. The devil is in the details of the content. We need to know what type of content you clicked on (and with what level of nesting) so we understand the edge case. A sample document is usually best.

[ldez]

I'll close this issue, because I think the question is answered, but feel free to continue the conversation.

[mojavelinux]

Actually, it might not be answered. If the preview is scrolling to the top but the cursor is not at the top, then this is perhaps a bug. We are waiting to verify.

[normoes]

Description

This is my workspace with the some of the code, nothing special here - It goes on like this afterwards and before. When I click alternatively on the preview tab and on the README.asciidoc, I try to click not always in the middle of the README.asciidoc tab - sometimes (far) above the middle or below it, but I never scroll. The top of the screen is by far not the top of the document.

Screenshots

Syntax example

==== docker volumes in redhat SELinux
[IMPORTANT]
====
On linux distributions using SELinux it is necessary to add `:z` or even better `:Z`
====