Prevent selection of line-returns in command mode

[mcolyer]

In vim, you can only select line returns when in insert mode, as specified in this spec https://github.com/atom/vim-mode/blob/v0.1.0/spec/vim-mode-spec.coffee#L50-L59

I'm not exactly sure the best way to handle this given the current editor API. @probablycorey or @nathansobo any ideas on how to approach this?

[mcolyer]

So I dug a bit further into this, I think it would be good to handle this the same way we handle text input events, by selectively blocking events.

It looks like when a Cursor moves, it triggers a 'moved' event which the corresponding CursorView then watches. When the CursorView receives a move event it marks the CursorView as dirty. Finally the next time the editor calls updateDisplay it gets redrawn.

Ideally there would be a way to preempt the Cursor event when the cursor is located on the last character of line. Does this approach make sense?

I think this means extending EventEmitter with an additional method ('preempt') and creating a preempt queue for every event. It would then iterate over all preempt callbacks before calling the normal callbacks and if one of the preempt callbacks returns false it would stop otherwise all callbacks would be run.

PS, when I read the source it looks like Cursor actually triggers 'moved' but CursorView listens for 'moved.cursor-view' how does that happen?

[probablycorey]

I'll answer the PS real quick. In JQuery namespaced events are created with
the pattern "name.namespace". This way you can remove all namespaces events
from an object. In this case, 'cursor-view' is the namespace and 'moved' is
the event name'

On Mon, Aug 5, 2013 at 1:20 PM, Matt Colyer notifications@github.comwrote:

So I dug a bit further into this, I think it would be good to handle this
the same way we handle text input events, by selectively blocking events.

It looks like when a Cursor moves, it triggers a 'moved' event which the
corresponding CursorView then watches. When the CursorView receives a move
event it marks the CursorView as dirty. Finally the next time the editor
calls updateDisplay it gets redrawn.

Ideally there would be a way to preempt the Cursor event when the cursor
is located on the last character of line. Does this approach make sense?

I think this means extending EventEmitter with an additional method
('preempt') and creating a preempt queue for every event. It would then
iterate over all preempt callbacks before calling the normal callbacks and
if one of the preempt callbacks returns false it would stop otherwise all
callbacks would be run.

PS, when I read the source it looks like Cursor actually triggers 'moved'
but CursorView listens for 'moved.cursor-view' how does that happen?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/2#issuecomment-22138003
.

[nathansobo]

We added a preempt method to jQuery by just unshifting the handler onto the array instead of pushing it. Seems like it could work similarly in this case, rather than using an entirely different array?

[nathansobo]

After pondering this, I wonder if we want the cursor to emit a will-move event, which allows us to return false from an event handler to block the move from occurring. This will probably necessitate some enhancement to the EventEmitter system to allow us to determine if any event handlers returned false. By the time the moved event is fired, I'm assuming the cursor has already moved and it will be too late. Am I missing something here?

[mcolyer]

Yep you're correct, the moved event is fired afterwards which is why we need this extra machinery. I'd be okay with the will-move solution. I guess it depends if we want a more general solution or if a specific solution here will suffice.

[nathansobo]

The generality won't cost us much in this case, I think. It's worth it.

On Wed, Aug 7, 2013 at 3:07 PM, Matt Colyer notifications@github.comwrote:

Yep you're correct, the moved event is fired afterwards which is why we
need this extra machinery. I'd be okay with the will-move solution. I
guess it depends if we want a more general solution or if a specific
solution here will suffice.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/2#issuecomment-22288149
.

[bronson]

Does this issue need to be fixed? It seems like vim-mode is currently doing a great job of not allowing the cursor to ever reach the newline. Do we need another layer of defense?

(if not, a search on vim-mode#2 reveals a little unused code that can be removed)