Scrolling to line number


#1

I want to get the top line number from one editor pane and then scroll another to match. They have identical contents. The one I’m getting the line number from was loaded with a TextBuffer.setText() and the one I’m scrolling was loaded from a file.

I’m using lineNum = editorView.getFirstVisibleScreenRow() from the first editor and atom.workspaceView.getActiveView().scrollToBufferPosition [lineNum, 0] to scroll the second.

My problem is that the second is scrolling to a line about 20 less than lineNum. lineNum matches what I see in the source’s view. But I don’t know whether that number is in buffer or view coordinates. The docs don’t say what coordinate space it is in. The setPos is in buffer coords. However, I have no wrapped lines so the coordinate systems shouldn’t matter, right.

Can anyone help?


#2

Quick note, folded code matters to. Also, for the screen synch scrolling stuff I think scrollToScreenPosition makes more sense https://atom.io/docs/api/v0.103.0/api/classes/EditorView.html#scrollToScreenPosition-instance


#3

I found the problem. In my testing I was setting the editor cursor position(setCursorBufferPosition) after scrolling the editorView(scrollToBufferPosition). The setCursorBufferPosition autoscroll was changing the scroll position.

However, setCursorBufferPosition wasn’t supposed to cause a scroll. The cursor position was only a few lines from the top but the auto-scroll decided to scroll everything so the cursor ended up near the bottom.

So there is some problem in the autoscroll functionality. When I get a chance I’ll make a simple example showing the problem and submit the issue to atom/atom.

For now I’m just turning off autoscroll.


#4

aarrgghh

In further testing, even with autoscroll turned off the scrollToBufferPosition call would go to the wrong line. I even commented out setCursorBufferPosition and it did the same thing. It scrolled to near the bottom. This is the same place that setCursorBufferPosition would go to with autoscroll turned on.

Scrolling is screwed up. This might have something to do with the other bug I submitted where the message EditorScrollView scrolled when it shouldn't have. appears in the log. I guess I am going to have to debug this in core. Fun fun fun.


Synchronised Scrolling Between Panes
#5

I’m sure no one has followed my bitching this far and I’m talking to myself but here goes.

Once again I think I understand what it going on. When scrollToBufferPosition is called, it doesn’t scroll such that the pos is at the top of the screen, it just scrolls wherever it wants as long as that pos is visible somewhere on the screen. This is pretty much useless.

This scrolling is critical for my package because you switch rapidly through versions of the file and without proper scrolling the screen jumps around making it really hard to follow. I’ve been working on this package full time for exactly a month and now It’s going to suck.

I’ll take another look at scrolling in the core and see if I can fix it.


#6

I’m not sure, but it appears that the center option for scrollToBufferPosition can be used to get around this problem. I was assuming it should align the top of the screen without the center option but as I have found out after busting my butt for the last 24 hours and posting all these messages I should have used the center option from the beginning. You cannot align the tops.


#7

I’ve been reading, I just haven’t had anything helpful to add :smile:


#8

It’s not perfect. The center option for scrollToBufferPosition failed once out of 100 tests. Oh well, that’s good enough I guess. I’ll shut up about this now.


#9

It sounds like centering may end up making more sense and you were just fixated on top of screen? (Personally I do that a lot :smile: ) Lots of tools behave this way.

BTW, you should take a look at vim-mode. Traditional H (is supposed to take you to the top line traditionally) it takes you as high as it can, but sometimes it pushes you up a bit. It’s VERY funky, but I’ve never once disliked it. I actually love it, because I want to see some context above.


#10

If something can expand and contract then anchoring the top is best. Better to have the bottom extend off the page instead of both the top and bottom. I’m also used to CSS where you specify the top when you set scroll position. Actually I’ve never heard of scrolling to a center before.

is supposed to take you to the top line traditionally

I think you mean the cursor, right? There is no problem setting the cursor to top, middle, or bottom. It is easy and makes sense. Scrolling the page is quite different.


#11

Yes traditionally in vim the screen wouldn’t move but the cursor would. When you move the cursor to the top in Atom the screen scrolls, that’s all I meant.

There was a question mark after the fixated part. I have no idea.