| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
If we're in edit mode and the user changes tab, we lose the focus. That
causes edit mode (and any sub mode like visual mode) to exit. When we
return, we're in insert mode!
With this commit, we save the state, and restore it when appropriate.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
There's an efficient way to implement reverseSelection, and an
inefficient way. Unfortunately, the efficient way does not work for
text inputs like textareas. So we fall back to the inefficient method
in that case.
|
|
The UX around find in visual mode can be a bit weird. It may be better
to remove it.
|
|
|
|
|
|
|
|
|
|
- "dw", "3dw", "d3w"
- "dc", "3dc", "d3c"
- "D"
- "C"
Also refactor enterInsertMode.
Also major refactor of interface between edit and visual modes.
|
|
|
|
|
|
- implement "i", "a".
- fix "w" for edit mode.
- try out "e" for enter edit mode.
- initial implementation "o", "O"
- Suppress backspace and delete.
- Scroll in text areas.
|
|
There are cases where the faster approach gets the wrong answer.
|
|
|
|
- Better abstraction.
- Add HUD message on yank.
- Require initial selection for visual mode.
- Try to start with a visible selection.
- Scroll the active end of the selection into view (with smooth
scrolling, if enabled).
|
|
|
|
- Some better comments.
- More commands.
- The "o" command for visual mode (the implementation is poor, there has
to be a better way).
|
|
These modes turn out to be almost identical. So they're better off in a
single file.
|
|
|
|
|
|
|
|
This allows us to select contentEditable elements in the same way as we
can select other inputs.
Fixes #1437.
|
|
focusInput was getting its focus events from the handler stack. When
the handler stack was reset during tests, we lost focusInput's handler.
So we couldn't test the feature whereby focusInput has a memory (#1438).
Instead, here focusInput adds its listener directly to the window, and
we add the approriate test.
|
|
into modes-rework-dom-tests
|
|
|
|
|
|
This uses phantomjs to generate keyboard events. So the events are
propagated through the regular event listeners. So we're testing the
full keyboard-event flow.
|
|
- Set up modes such that they can be re-initialised.
- Move initialisation of BadgeMode to general initialisation function.
- Add reset() method for handlerStack.
- Consistently use initializeModeState() in all tests' setup().
- Refactor focusInput tests.
- Add some more tests.
- Simplify some other tests.
Note: Clean-up of the inputFocus overlay now happens when the exit()
method is called in Mode.reset(). This eliminates most needs to
artificially bubble a keyboard event to clear the overlay.
|
|
Give focusInput (gi) a memory
|
|
On simulateSelect, do not change selection if selection exists.
|
|
There's no point in focusing element if it's already active.
Also, we leave the caret in place, not just a range selection.
isSelected makes the wrong decision if the user has placed the caret at
the start of element. We cannot distinguish that case from the user
having made no selection. Nevertheless, this is substantially better
than the existing UX, which *always* moves the caret to the end.
|
|
|
|
This uses phantomjs to generate keyboard events. So the events are
propagated through the regular event listeners. So we're testing the
full keyboard-event flow.
|
|
Caught this while working on the dom_tests infrastructure. Testing
works!
|
|
- Set up modes such that they can be re-initialised.
- Move initialisation of BadgeMode to general initialisation function.
- Add reset() method for handlerStack.
- Consistently use initializeModeState() in all tests' setup().
- Refactor focusInput tests.
- Add some more tests.
- Simplify some other tests.
Note: Clean-up of the inputFocus overlay now happens when the exit()
method is called in Mode.reset(). This eliminates most needs to
artificially bubble a keyboard event to clear the overlay.
|
|
This makes the diff look big, but that's mainly due to a change in
the indentation.
|
