Redoing the Scroll Line Up/Down for the cmv3 branch

[TomMalbran]

This finally adds the Scroll Line Up/Down feature from #1837 using the defaultTextHeight function from CodeMirror3.

[njx]

On the Mac, Cmd-Up/Down are used for go to beginning/end of doc. I can't tell if there's a standard Mac shortcut for scroll line up/down, but Sublime uses Ctrl-Alt-Up/Down and TextMate uses Ctrl-Alt-Cmd-Up/Down (which seems like a lot of modifiers :)) I suggest Ctrl-Alt-Up/Down.

Is Ctrl-Up/Down standard on Windows?

[TomMalbran]

Yes Ctrl-Up/Down seems to be standard on Windows. Although is also the command to scroll to the end of the document (and beginning? never got this to work). Should I change it for both Mac and windows or use different commands?

[njx]

Let's use different commands for the two platforms. Regarding begin/end of document, it looks like the standard on Windows is to use Ctrl-Home and Ctrl-End, which we already support, so it's probably just a fluke that Ctrl-Up/Down are mapped that way in CodeMirror.

[njx]

Reviewed--looks good except for the Mac shortcut; see comment inline.

[TomMalbran]

Thanks. Just a question on the comment before doing a new commit to change it.

[njx]

One more comment (which is more substantial). I noticed that in both Sublime and Visual Studio, Scroll Line Up/Down try to keep the cursor on screen--i.e., if the cursor is on the last visible line and you scroll one line up, it moves the cursor up one line to keep it visible (and vice versa at the top of the screen). Seems like we'd want to do that as well.

[njx]

A couple more details:

Editors seem to be inconsistent if there's a range selection. In Sublime, if the selection is a range, it doesn't change the selection to keep it on screen if you scroll. In Visual Studio, if the selection is a range, it converts it to a cursor on the last line if it overlaps the edge of the screen at all.

Sublime doesn't seem to use "goal column" behavior when keeping the cursor on screen. Normally, if you set the cursor at (say) the end of a line, and then up or down arrow across lines of different lengths, the editor keeps a "goal column" that keeps track of where the cursor should be if it moves to a short line and then back to a longer line. (For example, if you start at character position 30, then arrow down to a line that's only 20 characters long, it will move the cursor to the end of that line at position 20, but if you arrow down again to a line that's longer than 30 characters, it goes to position 30 on that line.) Sublime does this for the arrow keys, but if you line-scroll in a way that moves the cursor off, it just resets the cursor position and doesn't remember a goal column. I haven't checked Visual Studio to see what it does. This is a pretty fine nuance in any case, but it would be nice to use goal column behavior (which is build into CodeMirror, but I'm not sure if there's a way to access it externally).

[TomMalbran]

Changed the key bindings to Ctrl-Alt-Up/Down on Mac and Ctrl-Up/Down on Windows.

I made an implementation of what Sublime does keeping thee cursor in the screen and it works but I needed to know the height of the editor and editorHeight is not implemented on cmv3, so I used jQuery to find it from #editor-holder, but it wont work with an horizontal scrollbar, so this might need to wait until that function is implemented, unless there could be another way to know the first and last visible lines in the main editor.

I also used CodeMirror.moveV function directly from editor._codeMirror, since using it keeps the goalColumn, while setCursor sets it to null, so even if is accessible via CodeMirror.view.goalColumn, is not usable with setCursor. Should I add this function to Editor.js, or just leave it like it is?

[TomMalbran]

I had problems updating the branch with the latest commits recently to solve the editorHeight problem. But since the current Sprint is about to end and the CodeMirror v3 will be updated in Brackets, I am closing this pull request and remaking it once the Sprint 20 is done.