Feature request: make use of the scroll lock key

[jarreboum]

Description of the Issue

The Scroll Lock key is grossly underused these days, and sits alone on the keyboard, barely ever pressed. Notepad++ ought to correct that.

Steps to Reproduce the Issue

1. Move the cursor around with the cursor keys
2. Press the scroll lock key
3. Try using the cursor keys again

Expected Behavior

The whole document should scroll, while the cursor stays in the same position relatively to the screen.

Actual Behavior

The cursor keeps moving.

Additional information

Maintaining Ctrl and using the cursor keys somewhat emulates this behaviour. This is unsatisfactory as:

• Both hands have to stay on the keyboard, unlike other modifier keys like Caps lock and Insert.
• The cursor stays in its position relatively to the document (same line), and the user as to "catch up" with the document with the cursor keys or the mouse.
• It doesn't work with Page-Up/Down.

Debug Information

Notepad++ v7.5.1 (32-bit)
Build time : Aug 29 2017 - 02:35:41
Path : C:\Program Files (x86)\Notepad++\notepad++.exe
Admin mode : OFF
Local Conf mode : OFF
OS : Windows 10 (64-bit)
Plugins : mimeTools.dll NotepadStarterPlugin.dll NppConverter.dll NppExport.dll NppFTP.dll PluginManager.dll

[SilverGreen93]

I vote for this! Most similar apps should implement this.
Seems that is not hard to be done, as Ctrl+Arrow key has a very similar behaviour.
Hope to see it soon in Notepad++

[NishitCodes]

Definitely needed.

[sasumner]

while the cursor stays in the same position relatively to the screen.

The caret isn't necessarily always visible to the user. Example: Put caret on line 1 of a file that has more lines than will fit on on-screen at once. Then, using mouse, click and drag the vertical scrollbar such that line 1 (with the caret) is no longer visible. What is supposed to happen in the proposed scroll-lock scenario for this case?

[jarreboum]

The caret isn't necessarily always visible to the user.

Which is part of the bug I'm reporting.

Picture your mouse cursor: it doesn't move on your display when you scroll down, but points at a different part of your text. The caret would behave the same with scroll lock.

But scroll lock is really about keyboard-only workflows. Where you don't want to move your hands away from the keyboard when you are editing a document and need to move to another part of it: press scroll lock, move the document a few lines up or down with the cursor keys, press it again to unlock the caret. Having the caret stay at the same document line defeats the purpose of being able to move the document with the keyboard, as you still need to grab the mouse to position the caret.

[Ekopalypse]

@jarreboum - if such a feature should be considered I would try to define its functionality as good as possible.
I would assume that one might be willing spending their time to code this more easily if one doesn't have to
do the research also. I mean, you already know what you expect by pressing different keys when scroll lock is activated, the one who possibly will try to work on it might have a different idea.
After reading your FR the questions immediately coming into my mind are:
Which keys should be considered doing some moving actions?
And what should those keys do exactly?
What is expected after unlocking the scroll?
Should other keys, other than "moving keys", be allowed when scroll lock is active?
What if one tries to select text with the mouse while scoll lock is active?
...

[SebastianHelm]

@jarreboum:
The scenario you describe does not require scroll lock. If a user who wants to move the caret (insertion point) to another part of the document, she can just move it with the existing functionality; there is no need to lock and unlock scrolling.

Part of the advantage of scroll lock is precisely that it leaves the IP in place, but the implementation you're suggesting would compromise that. Moreover, to force a change of the IP with respect to the document would be unexpected and disruptive.

That said, one can think of a scenario in which it would be useful to set the IP to the current mouse position
with KB only. For instance, if one wants to peek at another part of the document before cutting the selection and then pasting it to the new location. For such cases, I would suggest reserving one key or key combination to do just what you need: Simulate a mouse click. The choice of key could be left to the user, if offered via the Shortcut Mapper. That should be a different FR, although it would dovetail with a scroll lock feature.

@Ekopalypse:
Along the lines of what I wrote before, a simple solution offers itself:
Arrow Keys: Simulate mouse click on the corresponding arrow buttons in the scroll bars.
PgUp, PgDn, Home, End: Simulate mouse click in the trough of the scroll bars above, below, left or right of the thumb.
All other keys: Behave same as in non-scroll mode.

However, one can also make the case for a more dedicated solution, for which I want to answer all your questions:

Single Keys for moving actions:
Up, Down: Scroll vertically by one row, just like ^Up, ^Down in non-scroll mode.
Left, Right: Scroll horizontally in by one screen width.
PgUp, PgDown: Scroll vertically by one screen width.
Home: Scroll horizontally so that the leftmost column is visible.
End: Scroll horizontally so that the rightmost used column is visible. (On a related note: NP++ currently sets the horizontal scroll limit far beyond that point. I see no reason why NP++ can't simply handle this like the vertical scroll limit, adjusting it to the document dimension.)
Tab: Move to next tab stop without inserting any character. One could consider making this dependent on the line under the mouse pointer, but I don't think that would be worth the trouble.

Key combinations with shift key:
+Any key: As defined above, plus: extend selection. This is not a big functional change to the current behavior in non-scroll mode, except that the IP always stays in the same position vertically, and horizontally if possible. That is, when a user presses +PgUp while the IP is in the center of the screen, the IP will still be vertically at the center, but its horizontal position may change depending on the content of the selected line. (When the end of the document is reached, one could consider displaying an edge, if that's not too much programming effort.)
+Tab: Move to previous tab stop; that is, exactly the opposite of Tab.

Key combinations with control key:
^Arrowkey: Scroll by about half a screen. Or: ←→Move word wise, ↑↓ move paragraph wise or to next folding level delimiter. That would be dependent on the text under the mouse pointer – same problem as mentioned under Tab.
^PgUp, ^PgDn: Scroll to about half the position between current display and begin resp. end of document.
^Home, ^End: Scroll to first or last page, as already implemented in non-scroll mode, except that it leaves the IP in place.

After unlocking the scroll:
Nothing happens. Selection and IP remain as they were. If user presses any key that requires screen updating, do that as usual so that it's appropriate for the selection after the key was pressed. (Basically this is the same as described in more detail in the next point.)

Non-moving keys:
One can see good arguments for either allowing or forbidding other keys. However, I think the arguments for allowing prevail. Behavior should be:

1. Act with reference to the current selection and IP.
2. Update screen to show IP and as much of selection as possible, with secondary condition to change view as little as possible.
   This behavior is already implemented when user moves scroll bar; so there is no new coding required.

Mouse always selects the text that is under the mouse; this behavior should be no different from non-scroll mode.