Scroll to the first line when the preview hits top

[ggrossetie]

Since the document title does not have a data-line attribute when we scroll to the top on the preview it does not scroll to the document title (but to the first block).

I didn't find a way to do the opposite (i.e., when we scroll to the top of the AsciiDoc document, scroll to the top of the preview). The reason is that we cannot tell what is on the first line. I guess we could read the first line and check if it's the document title but even then the document title could be hidden in the preview with :showtitle!:.

So this pull request partially fixes #348

[ggrossetie]

I didn't find a way to do the opposite (i.e., when we scroll to the top of the AsciiDoc document, scroll to the top of the preview). The reason is that we cannot tell what is on the first line. I guess we could read the first line and check if it's the document title but even then the document title could be hidden in the preview with :showtitle!:.

Arguably, we could scroll to top no matter what... I think this is the expected behavior anyway. Thoughts?

[danyill]

Thank you, I think we have an off by one error. It is an improvement and I apologise for being a little niggardly...

[danyill]

I didn't find a way to do the opposite (i.e., when we scroll to the top of the AsciiDoc document, scroll to the top of the preview). The reason is that we cannot tell what is on the first line. I guess we could read the first line and check if it's the document title but even then the document title could be hidden in the preview with :showtitle!:.

Arguably, we could scroll to top no matter what... I think this is the expected behavior anyway. Thoughts?

I am not sure, I probably wouldn't put much effort into it. I don't think the preview and source should be "perfect" because the underlying alignment is not 1-to-1 (we have hidden things, comments, document attributes etc.).

I am concerned about side effects and jumping back and forth for a single line change for large document headers. There is already a problem like this at the bottom of some documents which I've experienced where the preview and source pane flutter alarmingly whenever you scroll below a particular point. On small form factors or when the window isn't maximized this could be an issue, perhaps when you scroll after the title or after the document attributes or to the first data-line-x value.

We also have this problem for tables where which cross more than one screen because we can't allocate data-line-x on the table cells or rows.

I guess the proof would be to implement it and see if it can be made suitably robust.

[ggrossetie]

I am not sure, I probably wouldn't put much effort into it. I don't think the preview and source should be "perfect" because the underlying alignment is not 1-to-1 (we have hidden things, comments, document attributes etc.).

That's true but when the scrollbar hits the top (or the bottom) it should also hits the top (or the bottom) of the preview/editor.

I am concerned about side effects and jumping back and forth for a single line change for large document headers. There is already a problem like this at the bottom of some documents which I've experienced where the preview and source pane flutter alarmingly whenever you scroll below a particular point. On small form factors or when the window isn't maximized this could be an issue, perhaps when you scroll after the title or after the document attributes or to the first data-line-x value.

Here's the result:

Not sure if it's possible but we could "smooth scroll" instead of "jumping".

In my opinion, today it's even worse since you cannot have both scrollbars at the top (i.e., show the document title on both the preview and the editor):

We also have this problem for tables where which cross more than one screen because we can't allocate data-line-x on the table cells or rows.

As far as I know this improvement does not improve or worsen the situation regarding tables.
We can address this concern but not as part of this pull request since that's another issue.

I guess the proof would be to implement it and see if it can be made suitably robust.

I did and I think it's better, now both sides will be synced when they reach the top.

[danyill]

I did and I think it's better, now both sides will be synced when they reach the top.

I agree, thanks for this! Let's do it.