| Age | Commit message (Collapse) | Author |
|---|
|
- Collapse to focus when entering caret mode from visual mode.
|
|
|
|
|
|
- When the user exits visual mode via escape, we reinstall the original
selection (from launch).
|
|
|
|
|
|
|
|
|
|
When visual mode launches and there *is* a selection but it's outside of
the viewport, instead of scrolling it into view, ignore it, and start
with a visible caret.
|
|
This reverts commit 90d2addc9b8f95f9272f8c2a77bdaf9dfebc0fa8.
Nope. This is bad. It fixes the issue referred to in the commit
record, but breaks scrolling out of text areas.
With 90d2addc9b8f95f9272f8c2a77bdaf9dfebc0fa8:
- Start editing in a text area, add enough text that it scrolls.
- `Escape`
- `k`, `k`, `k`, ...
We expect first the text areas to scroll, then -- when it reaches the
top -- the document to scroll. However, with
90d2addc9b8f95f9272f8c2a77bdaf9dfebc0fa8, we get stuck in the text
area.
|
|
This reverts commit 90d2addc9b8f95f9272f8c2a77bdaf9dfebc0fa8.
Nope. This is bad. It fixes the issue referred to in the commit
record, but breaks scrolling out of text areas.
With 90d2addc9b8f95f9272f8c2a77bdaf9dfebc0fa8:
- Start editing in a text area, add enough text that it scrolls.
- `Escape`
- `k`, `k`, `k`, ...
We expect first the text areas to scroll, then -- when it reaches the
top -- the document to scroll. However, with
90d2addc9b8f95f9272f8c2a77bdaf9dfebc0fa8, we get stuck in the text
area.
|
|
On this page:
- http://www.steephill.tv/dubai-tour/
I was seeing a scrolling problem in my live browser (j/k didn't work
until I clicked on the page), but couldn't reproduce it directly in my
test browser. That's worrying.
Nevertheless, what was happening was that we succeeded in scrolling a
test amount in one direction, but the scroll to revert failed. The
consequence was that we concluded (incorrectly) that the element doesn't
scroll. And j/k scrolling is broken as a result.
How can it be that a scroll in one direction succeeds, but the reverse
does not?
This fixes the problem by not checking whether we are able to undo the
scroll of our test amount.
|
|
On this page:
- http://www.steephill.tv/dubai-tour/
I was seeing a scrolling problem in my live browser (j/k didn't work
until I clicked on the page), but couldn't reproduce it directly in my
test browser. That's worrying.
Nevertheless, what was happening was that we succeeded in scrolling a
test amount in one direction, but the scroll to revert failed. The
consequence was that we concluded (incorrectly) that the element doesn't
scroll. And j/k scrolling is broken as a result.
How can it be that a scroll in one direction succeeds, but the reverse
does not?
This fixes the problem by not checking whether we are able to undo the
scroll of our test amount.
|
|
- And drop "J".
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- better definition of vimword.
- fix initial selection as just one character when entering caret mode.
- fix initial caret when entering visual mode from edit mode.
- better selectLine.
- "o" and "Y" are commands for visual mode, not movements.
- simplify find mode within visual mode.
- add FindMode binding for "/".
|
|
|
|
- Simplify the SuppressPrintable key handler.
- Rework the protectClipboard logic.
- Some commands (x, X, etc) never affect the clipboard.
|
|
|
|
|
|
|
|
|
|
It turns out we need to check different properties of the selection in
order to correctly detect when the selection has changed in
contentEditable elements.
|
|
Also, change how vim's "w" is implemented.
Also some code-review/cleanup.
Better dd and yy for gmail.
|
|
- Use a has for singletons (as it was previously), but with a distinct
identity generated by Utils.getIdentity.
- Fix counts not be using in a number of places.
|
|
- Minor refactoring.
- Better selection of entity for "daw" an friends.
- dd uses count, and works for empty lines.
- Count for daw, etc.
- Fix bug whereby selection cleared when changing tabs.
|
|
- Minor changes.
- Deactivate modes on inputs from focusInput().
|
|
|
|
- Various argument forms for runMovement.
- Better visual line mode line selection.
- Include preceding white space for "daw" and friends.
- Vim-like handling of "2d3w" - count is six".
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
