You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In a TextConsoleViewer, as used by the Console view, scroll lock is automatically enabled or disabled under certain conditions. The basic idea seems to be that scroll lock is automatically disabled when navigating to the end of the view. But when pressing down/page-down, when scrolling, or when moving the scroll bar, scroll lock is even disabled if the navigation does not reach the end of the viewer (see also #649 (comment)). More precisely, it is disabled when after navigation the last shown line is less than X lines away from the last line of the viewer, where X is the line height in pixels. This is obviously unintended (comparing pixels with lines) and is particularly a result of a faulty implementation of checkEndDocument. However, it is not completely clear what the expected behavior would be.
The implementation compares line values (partialBottomIndex, lineCount) with pixels (the scroll bar increment delta), which obviously does not give correct results. The method checkStartDocument is equally faulty, but simply results in always returning false.
Expected Behavior
It is not completely clear what the currently intended behavior is. But it looks to me as if scroll lock should be disabled in case scrolling reaches the end of the view or if the end is already reached and some down-navigation key is pressed. And it should enable scroll lock whenever some up-navigation is performed if the topmost line has not already been reached.
Options
I see different options for the expected behavior under certain conditions.
When to do nothing:
(Current) When the view contains less lines than can be display (i.e. when no scrollbar exists).
(Probably current intention) Pressing some up-navigation key while the first line is visible.
When pressing some up-navigation key while the cursor is in the first line.
When to disable scroll lock:
(Probably current intention) As soon as the view is scrolled to the end.
(Probably current intention) When pressing some down-navigation key while the last line is shown.
When pressing some down-navigation key while the cursor is in the last line.
(Current) When moving to the document end via CTRL+END.
As soon as the cursor reaches the end of the contents.
When to enable scroll lock:
(Probably current intention) Whenever an up-navigation is performed and the first line is not visible.
(Current) When moving to the line start via HOME.
Whenever an up-navigation is performed while the cursor is not in the first line.
Whenever any up/down navigation is performed (key press or dragging the scroll bar) and the navigation did not move the cursor to the end of the contents.
Whenever any navigation (including left/right) is performed (key press or dragging the scroll bar) and the navigation did not move the cursor to the end of the contents.
Proposed Option
I propose the following target behavior:
Nothing is done when pressing some up-navigation key while the cursor is in the first line
Scroll lock is disabled when:
the view is scrolled to the end
the cursor is in the last line and some down-navigation is performed
CTRL+END is used
Scroll lock is enabled when:
the view is scrolled and is not at the end
any vertical navigation is performed other than the ones disabling scroll lock
In particular, I would propose to always enable scroll lock when navigating vertically and not only when pressing some up-navigation key. When I start to navigate within in a console viewer (even using the down button), I usually want to do something at that very position and don't want to have the console keep scrolling.
Opinions
What opinions do you have with respect to the expected behavior?
The text was updated successfully, but these errors were encountered:
Current Behavior
In a
TextConsoleViewer
, as used by theConsole
view, scroll lock is automatically enabled or disabled under certain conditions. The basic idea seems to be that scroll lock is automatically disabled when navigating to the end of the view. But when pressing down/page-down, when scrolling, or when moving the scroll bar, scroll lock is even disabled if the navigation does not reach the end of the viewer (see also #649 (comment)). More precisely, it is disabled when after navigation the last shown line is less thanX
lines away from the last line of the viewer, whereX
is the line height in pixels. This is obviously unintended (comparing pixels with lines) and is particularly a result of a faulty implementation ofcheckEndDocument
. However, it is not completely clear what the expected behavior would be.More technically:
eclipse.platform/debug/org.eclipse.ui.console/src/org/eclipse/ui/console/TextConsoleViewer.java
Lines 159 to 168 in f385650
The implementation compares line values (
partialBottomIndex
,lineCount
) with pixels (the scroll bar incrementdelta
), which obviously does not give correct results. The methodcheckStartDocument
is equally faulty, but simply results in always returningfalse
.Expected Behavior
It is not completely clear what the currently intended behavior is. But it looks to me as if scroll lock should be disabled in case scrolling reaches the end of the view or if the end is already reached and some down-navigation key is pressed. And it should enable scroll lock whenever some up-navigation is performed if the topmost line has not already been reached.
Options
I see different options for the expected behavior under certain conditions.
When to do nothing:
When to disable scroll lock:
When to enable scroll lock:
Proposed Option
I propose the following target behavior:
In particular, I would propose to always enable scroll lock when navigating vertically and not only when pressing some up-navigation key. When I start to navigate within in a console viewer (even using the down button), I usually want to do something at that very position and don't want to have the console keep scrolling.
Opinions
What opinions do you have with respect to the expected behavior?
The text was updated successfully, but these errors were encountered: