Creating a independent cursor

#1

Hi,

I’m having a few problems creating a new independent Cursor, we are using the addCursorAtBufferPosition(point) but it
binds this new cursor with the others. Is there a way to make it independent? I’ve tried to import the Cursor class so I could instantiate it but it’s not possible. I’m needing to do this to create a remote cursor for a package that I’m building to viabilize remote pairing called Motepair, creating a new cursor would let a co-pilot and the pilot have two independent cursors and give to it a nice experience.

Thanks.

#2

Create a marker at the position. Then add a decorator to the marker with CSS to draw the cursor. Maybe border-left: 1px solid somecolor.

#3

Hi Mark,

I’m also developing this package, and we tried already what you said. We tried out two option.

  1. The one you said. Using a decorator with the type being highlight, but this solution has a problem the cursor will only be visible if the marker is over a char, you can’t see it if you move to a empty line, the end of the line or if you move your cursor over the indent guide for example.

  2. We created a decorator with the type being overlay , but I don’t know if is a BUG or is it expected behavior, but every time you set the position, the marker is append one line after. For example, if you set the position to be [5,10] the marker will be plotted at position [6, 10]. I tried to just subtract 1 from the row, but when you reach the first line, the subtracted row will be -1 and the atom does not understand and plots the marker at the begining of the line, regardless the position.

Thanks Mark.

#4

I see you solved this in item 2.

Line indexes are zero-based except where the line numbers are actually displayed. You will see +1 and -1 but only in the view code.

You should never have to do that. Just use zero-based lines everywhere. Let me know if there is any place this doesn’t work.

#5

Hi Mark,

I got your point. But to be precise, it seems that atom is adding 2 not 1 as I said, as you can see in the image below. To add that red cursor I’m doing this:

      marker = @editor.markScreenPosition [0,10]
      @decoration = @editor.decorateMarker marker,
        type: 'overlay',
        item: this,
        position: 'head'

Screen Shot 2015-02-04 at 19.02.37.png900x316 63.6 KB

So, if what you said was right, the red cursor should be shown at line 1, given that I’m setting the [0,10] position. But that is not happening. Do you have any idea what might be happening?

Thanks.

#6

I have never used an overlay. Maybe someone else can help.

I don’t know what your this is, I’ll assume it is a view. Is it possible the view is offset?

I would suggest using the chrome inspector to look at the DOM for your view. I have found Atom’s html to be easy to read.

#7

Have you tried using a transfom: translate(0, -100%) on the overlay? If your overlay has the same height than a row it should fix this issue.

#8

Thanks Abe,

That worked pretty well. You saved my day.

Luiz Filho

#9

Just for reference, I found the code responsible for move one line down the overlay.

I do not agree with this approach, because assumes that you will always use a overlay decorator below the position you wanted. That made me ‘undo’ all this logic to use it.

#10

Agreed, this is very confusing.

Could someone point me to a place where @abe’s trick is used. So I can match all of the numbers / offsets.

#11

Have you looked at @abe’s pigments package? If you set the “Marker Type” in the pigments settings to “dot”, it floats colored dots at the end of the line that match the colors mentioned on the line:

#12

Actually I don’t use overlay decorations in Pigments, for the dots it means to creating an additional marker spanning the end of the line so that the overlay decoration can stick to that position (and using the translate trick to make it appear on the proper line), but colors doesn’t necessarily appears at the end of a line, and I need to keep markers for individual colors to detect when a color is edited so I dropped this option (and the fact I have some other kinds of display also plays in this regard).

#13

Hah, so I was still working through this (why I haven’t replied).

Your dot works for me still on my machine but it appears to always show at the end of the lines not always in the same spot (btw, I much prefer the default background for pigments of course :smile: )

FYI, for background, I’m trying to make https://atom.io/packages/jumpy work with markers/decorations and I’m so close. Honestly I think the remainder of the issues is just a bug in the decorations.

I had to do this because the last changes to virtualization/tiling has dramatically slowed down Jumpy. It’s taken me a while to get through the rewrite, and kind of stuck on this bug holding off the release.

Basically if I subtract 1 from the last visible lines it works, but the last line can’t be jumped to. If I don’t subtract 1, when there is buffer beyond the screen, the line always returns one beyond the fold and the labels jump up and overlay on screen (they have no business being there)… It’s almost like a box model issue. I guess I have to work through the decorations code and find why it’s repositioning these on screen. I guess this all relates to fetching one more row for virtualization. For Jumpy though, there’s no reason I shouldn’t be able to get an exact read of visible lines at the time of toggle…right?

If anyone is curious the branch is here:
https://github.com/DavidLGoldberg/jumpy/tree/use_markers_and_decorations

#14

BTW, in general, my work with decorations using the highlight mode is much easier than overlays, go figure :smile:

#15

Yeah, I still got that from time to time, it looks like there’s some residual markers from previous sessions that affects the positioning (I need to count the markers for each line), but now that I found a way to implement colors in gutters I should be able to make the dots works with overlay decoration instead.

If you’re creating a lot of markers you should probably take a look at marker and decoration layers (I’m not sure if there’s any documentation yet) that are available at least in master (didn’t looked if it was released as part of the latest beta).

#16

Interesting haven’t heard of the layers, but what I meant was Jumpy originally had no notion of markers / decorations. I did it all from scratch, especially because Jumpy predates some of that stuff anyway, I think…

One of the calls in the old methodology (some read on screen info) was causing a huge perf hit. I noticed it’s already being called in cycle for the marker/decoration engine, so I realized I should just jump on the bandwagon, and the performance of the new branch is definitely quick again.

The only outstanding issue is this crazy last line bug. A little hard to explain, but some of the labels that are returned from below the status bar bump up above the status bar…Again, if I -1 to the count well then I really lose the last line, so I’m stuck in some catch 22 with regards to the bounds… very weird.

#17

Need some advice,

I thought I had read somewhere that editor.getVisibleRowRange() was being deprecated and we were supposed to use editorView.getVisibleRowRange() but deprecation cop doesn’t complain with either.

The above issue I was having was completely because I switched over to editorView… the editor.getVisibleRowRange() which I originally had turns out fixes everything again :frowning:

I got stuck thinking I was supposed to get back a few more rows and just handle the overlays beyond the fold…

Does this sound ok? Performance is fine, so I’ll almost definitely push it but why can’t I find the getVisibleRowRange() in the docs? Where should I be looking?

BTW, What’s up with textEditorView doc still missing a link? That’s been broken for maybe even a year? Is it not fully supported is that why maybe?

#18

Before v1.0, there were pairs of classes like Foo and FooView. The problem was that there wasn’t a great dividing line in the public API between the two. Some things that people thought should be on one were on the other and vice versa. So Atom did away with all of the View classes in the public API. The classes, in some cases, still exist in the codebase but they haven’t been part of the public API in probably a year.

Now, if you want to manipulate an editor, you work with the TextEditor class. The only time you need the “view” is when doing raw DOM manipulation or certain API calls. But even still, it isn’t a TextEditorView class … I think what you get back from atom.views.getView(editor) is a TextEditorElement class, at least at the time of this writing. And it is not part of the public API … use at your own risk.

Because it is not part of the public API. It isn’t supported and may change or even be removed at any time.

#19

Right element class sorry.

Ah, so I see, the getVisibleRowRange() however, is there an official way to do that at the moment?

Thanks for all of the clarification!

#20

There isn’t a way through the public API, no. Do I really think the getVisibleRowRange() method is going to go away or change significantly? Probably not. But you should be mindful of the risks.