Lister: cursor jumps into the visible area after Ctrl+arrows

[Flint]

Came from the discussion here.

1. Open some large file in the Lister (no plugins), turn the caret on.
2. Scroll the document with Ctrl+down for several lines.
3. Press any arrow key (up/down/left/right).
Expected: the cursor should move relatively to its current position and then the document should be scrolled to show the cursor (as in most text editors).
What happens instead: the cursor jumps to the neraly-visible area (to the line just above the visible area), and then moves in the direction specified by the arrow key, then the document is scrolled (if necessary).

PS: The same when scrolling with mouse wheel instead of Ctrl+down.

[ghisler(Author)]

This behaviour is inentional. Nothing is more frustrating than searching for many minutes for a certain text, and when it is finally found, lose the position because the cursor is somewhere else...

[Flint]

Nothing is more frustrating than searching for many minutes for a certain text, and when it is finally found, lose the position because the cursor is somewhere else...

But all text editors behave in the manner I described. The users get used to it, and may find it confusing how TC behaves in such situations.

Maybe a wincmd.ini key then? The current behaviour is really very inconvenient and unusual! (For me, at least...)

[SanskritFritz]

I bump this thread, because I wholeheartedly agree with Flint. Maybe optionally, please?

Another problem with the cursor movement:
When scrolling the screen with Ctrl-Up or Ctrl-Down, the cursor disappears after reaching the top or bottom, and behaves inconsistently, on the top it stays resident, on the bottom it jumps to the position last visible on screen. Can you please make the cursor simply stay on the screen when scrolling (yes this would mean cursor movement)?

[petermad]

2SanskritFritz

That's not what I experience. I actually have the behaviour that Flint described:

Expected: the cursor should move relatively to its current position and then the document should be scrolled to show the cursor (as in most text editors).

And when pressing Left/Right/Up/Down after scroling with Ctrl+Up/Ctrl+Down (or mouse scroll) then there is always scrolled so that the cursor is in line 4, exept if the cursor is in line < 4 already, or if the cursor is still visible (then there is not scrolled).

[StatusQuo]

Another problem with the cursor movement:
When scrolling the screen with Ctrl-Up or Ctrl-Down, the cursor disappears after reaching the top or bottom, and behaves inconsistently, on the top it stays resident, on the bottom it jumps to the position last visible on screen.

Partially confirmed here (Win2k SP4):
- Ctrl-Up/-Down both move the cursor out of the visible area,
- pressing cursor LEFT or RIGHT scrolls back to cursor position,
- cursor UP or DOWN set the cursor to random (?) positions => I'd consider this a bug.

- Viewing a binary file in binary mode (option 2) the restored cursor position seems to be completely random, also on cursor LEFT / RIGHT (maybe because of missing EOL-characters? tested with a PDF).

- Viewing in text mode (option 1): cursor keys
LEFT/RIGHT behave as expected (scroll to last cursor position, then move cursor),
UP/DOWN do not (move cursor to a random position or the 1st/4th line on top of the actual screen).

Examples:

Code: Select all

- set cursor to a position you can recognize, about half a screen above the file end
- scroll up with Ctrl-UP
- press cursor key UP or DOWN (fail, while LEFT / RIGHT work as expected here)

=> the cursor jumps to the very end of the file, only the last 4 lines are displayed at the top of the window.

Code: Select all

- set cursor to a position you can recognize, about half a screen above the file beginning
- scroll down with Ctrl-DOWN
- press cursor key UP or DOWN (fail, while LEFT / RIGHT work as expected here)

=> the cursor jumps to the first line of the displayed window.

Occasionally it jumped to line 4 instead of line 1 during the test, but I can't remember the condition for this.

[petermad]

2StatusQuo
I can confirm your observations. Apparantly I hadn't testet the Up/Down situations well enough the first time