Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added support to CMD+Left/Right for Mac navigation #380

Merged
merged 1 commit into from May 5, 2016

Conversation

atonse
Copy link
Contributor

@atonse atonse commented May 4, 2016

In MacOS, in addition to CTRL+A and E for "Home" and "End", another commonly used combination is CMD+Left for Home, and CMD+Right for End.

This commit adds those shortcuts, and pulls out the "getStartOfLine" and "getEndOfLine" functions out so they can respond to multiple command keys.

Regarding tests: I didn't find any tests for the existing Home/End key commands, so I didn't add anymore. But I have run the test suite and have noted no regressions.

@bantic
Copy link
Collaborator

bantic commented May 4, 2016

@atonse Thanks for this PR! I think this was addressed by #378 . That code hasn't been released yet, though.

Cursor movement via key presses is one of the few places in mobiledoc-kit that we still allow some of the native browser behavior. This is mostly done because the heuristics involved to position correctly from up/down keys are challenging (where your cursor moves when you hit up-arrow is dependent on current cursor position, font metrics, and also where the cursor was previously on that line) so we let the native browser cursor movement happen and then read the window's Selection from DOM again if the key was a movement key.

That said, explicitly handling home/end movement seems like a good idea, rather than trusting that the browser will put the cursor in the place we expect it to.

Adding key commands for cmd-up and cmd-down also seems good. These would focus on post.headPosition() and post.tailPosition(), respectively.

@bantic
Copy link
Collaborator

bantic commented May 4, 2016

Looking again now, I see that #378 deals with fn+LEFT (keyCode 36 aka Home) and fn+RIGHT (keyCode 35 aka End), so it is not the same.

@bantic
Copy link
Collaborator

bantic commented May 4, 2016

An acceptance test like this one would be the ideal sort of test for these commands.

@atonse
Copy link
Contributor Author

atonse commented May 4, 2016

@bantic the other navigational element is Alt/Option+left and right (go back and forward by a word). It was easy to add this PR since I just had to copy CTRL A/E behavior. But if you could point me to the right direction (like what you normally do to walk back until you find the next whitespace), I could add these other two.

Lastly, Shift + all of these should continue adding to the selection.

I don't envy you guys – this long tail of subtle behaviors can be endless.

@atonse
Copy link
Contributor Author

atonse commented May 4, 2016

@bantic I just tested and can confirm that CMD Up and Down at least moves to the top and bottom (including preserving the highlighted selection) but does not allow you to delete the selected text. I think in that sense, this is the same bug as #378.

@bantic
Copy link
Collaborator

bantic commented May 4, 2016

confirm that CMD Up and Down at least moves to the top and bottom (including preserving the highlighted selection) but does not allow you to delete the selected text. I think in that sense, this is the same bug as #378.

Agreed. 😢 It seems that no keyup event fires when releasing the up/down arrow while command is also held down (on Chrome on my Mac), so the editor never re-reads the DOM position. Even more reason to deal with these explicitly/semantically.

the other navigational element is Alt/Option+left and right (go back and forward by a word)

We have a section#textUntil(position) method that would make going backwards simple, but there isn't (currently) a textAfter method.

If you could add an acceptance test for the command-left and command-right I'd be happy to merge this PR as is and address the other movement combos separately. And I'd be very happy to help out on the follow-up here on github or through the gitter chat.

@atonse
Copy link
Contributor Author

atonse commented May 5, 2016

Ok thanks @bantic, i'll work on the test and get back to you.

@atonse
Copy link
Contributor Author

atonse commented May 5, 2016

Weird – I tested this locally using phantom (npm test) and all passed.

@atonse
Copy link
Contributor Author

atonse commented May 5, 2016

From my local testem:
screen shot 2016-05-05 at 10 44 56 am

@atonse
Copy link
Contributor Author

atonse commented May 5, 2016

Just realized this is MacOS only and the travis tests are failing for windows. I also added Firefox to my testem and have all local browsers passing. let's see how we do on windows.

@atonse
Copy link
Contributor Author

atonse commented May 5, 2016

All out of ideas – any suggestions welcome :)
screen shot 2016-05-05 at 11 07 56 am

if (Browser.isMac()) {
assert.equal(changedCursorPosition.offset, expectedCursorPosition, 'cursor moved to the end of the line on MacOS');
} else {
assert.equal(changedCursorPosition.offset, originalCursorPosition.offset, 'cursor not moved to the end of the line (non-MacOS)');
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think for windows this should actually assert that the cursor moves one character, not that it doesn't move at all.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I'm wondering about that because for me, Command on windows is the Windows Key, and Windows Key Left/Right actually are OS-level commands that rearrange your windows.

@bantic
Copy link
Collaborator

bantic commented May 5, 2016

@atonse I'll give this a run-through in windows quickly and let you know what I see. :)

let changedCursorPosition = Helpers.dom.getCursorPosition();
let expectedCursorPosition = 0; // beginning of text

if (Browser.isMac()) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah ha! isMac is not a function, it's a property. 😝

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops! Sorry about that. fixed and pushed.

@bantic
Copy link
Collaborator

bantic commented May 5, 2016

@atonse looks great! Can you please squash the commits?

In MacOS, in addition to CTRL+A and E for "Home" and "End", another commonly used combination is CMD+Left for Home, and CMD+Right for End.

This commit adds those shortcuts, and pulls out the "getStartOfLine" and "getEndOfLine" functions out so they can respond to multiple command keys.

Also fixed the triggerKeyCommand test method to accept non-alpha codes
@atonse
Copy link
Contributor Author

atonse commented May 5, 2016

@bantic squashed the commits.

@bantic
Copy link
Collaborator

bantic commented May 5, 2016

@atonse thank you!

@bantic bantic merged commit 9433e74 into bustle:master May 5, 2016
@bantic
Copy link
Collaborator

bantic commented May 10, 2016

released in v0.9.6

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants