Editor.clipScreenPosition() work?


#1

Does clipScreenPosition() work? Has anyone used it? When I used ag on my ~/.atom/packages I only got one result in a spec test for minimap.

Reason I ask:
When I put a debugger in the call back to observeTextEditors(editor) and use editor.clipScreenPosition(position) it works as expected.

Oddly, when I make the same call in the actual code and run through, I never see a difference in position vs the returned clipScreenPosition?

Am I losing context / this? Is it a race condition of sorts?


#2

I just ran the specs for the DisplayBuffer class (where the implementation for clipScreenPosition rests) and everything passed. It looks like the specs start here:

https://github.com/atom/atom/blob/master/spec/display-buffer-spec.coffee#L699

You may want to check them out and see if the specs match your expectations?


#3

I think that might be more internal to Atom right?

https://github.com/atom/atom/blob/master/spec/display-buffer-spec.coffee#L10

Links to an object not listed in the API, I think?

Or, is it really just one in the same with:

If I was reading that correctly, it has more options etc.


#4

TextEditor.clipScreenPosition just calls straight into DisplayBuffer.clipScreenPosition:

The DisplayBuffer class has the actual implementation. That’s why I looked there for the specs.

You are correct though that DisplayBuffer is not part of the public API.


#5

Here’s a snapshot of what’s confusing me:

Picture says it best, but basically I don’t expect the last output to have 59 as the column, as that is way beyond what I can visibly see. Now I know that if I inspect the “lines” the blue div box goes beyond the split pane. However this clipping behavior occurs if I make the whole window very small (for example 10 columns).

Basically it would be nice if the clippings mapped to the column that is at the width of the “scroll-view”. I realize there are virtualization issues to be aware of, but I’m ok forcing a block / read at the time of the call, as the screen won’t be scrolling.


#6

I might be using the wrong tool for the job. But my overlay decorations are breaking out of the current pane and overlapping on the test pane shown above… So my idea was to only paint the decorations that can actually be visible. I have the advantage of the “scroll-view” being lockable. In fact I remove the decorations with a scroll event.


#7

Yeah, I think it doesn’t mean what you think it means. Basically, I suspect what clipScreenPosition does is moves the Point that you pass it to the nearest valid screen position (as opposed to buffer position), not visible position. In other words, it moves the Point to the nearest valid position, taking into account soft wrap, folding and etc.