Cursor dom element in actual position


#1

I’d like to turn on a keybinding based on where the cursor is at (in this case, override another keybinding to do autocomplete when the cursor is in a place it could autocomplete, e.g. when it is immediately after a source tag. But the cursor is independent in the DOM, so I can’t tell where it actually is.

Is there a way to add a zero-width DOM element where the cursor actually is? ie something that would not be seen visually, but could be selected against (I assume selectors work this way, but don’t fully grasp them yet)


#2

You could also have a command that would check the cursor position and conditionally do one of two things, i.e. autocomplete or call the other command, and then bind that command to a key.


#3

Can you not use Editor::getCursorScopes for this?


#4

I imagine if I’m implementing leedohm’s idea, that I can. But if I’m doing that, then I’m hacking around the provided mechanisms of using CSS selectors. Like, either the selectors work, or they don’t. And if they don’t, then they should be removed because it’s additional code and cognitive overhead which I have to realize must be circumvented.


Also, this is how I’m attempting to do it right now:

'.editor':
  'escape':         'unset!'

'.editor .source':
  'escape':         'autocomplete:toggle'

which isn’t working, but I can’t figure out why, since every time I press escape, the keybinding resolver gets closed! Guess I could try unsetting all of those and then like binary search it to figure out which one is overriding, it’s just that I think my selector should has higher specificity (I’m assuming the matching selector is based on where the cursor is, which I think is what defines the active element, but it would be really convenient if I could see what DOM path is being matched against). Probably this is all stuff I can implement myself if I learn more about how the editor works, but it would still make it more accessible to dabblers like me if reflective tools like this were available.


#5

I think the reason this doesn’t work is because the key events get fired on the editor itself and not the elements that make up the highlighted text, since the editor uses various tricks including a hidden input where keys actually get collected.

You’re in luck though. Atom was recently changed to add the grammar scope to the editor element as a data attribute. So you can modify your selector to .editor[data-grammar~=source] and that should fix it without needing any unsets.

That will only work for the entire document however. If you really need finer control about where in the editor event activation should work, you will need to create a custom command and use the getCursorScopes function. Something like this:

atom.workspaceView.on 'autocomplete:toggle-if-source', (e) ->
  if atom.getActiveEditor().getCursorScopes()[0].substr(0, 6) is 'source'
    atom.workspaceView.trigger 'autocomplete:toggle'
  else
    e.abortKeyBinding()

Except with much better checking of scopes…

The call to e.abortKeyBinding will cause Atom to abandon the current command and move onto the next one, which sounds like what you need.