#615 TCoolEdit misplaces the caret

[Erwin Lotter]

After deleting the end of a line, the cursor seems to be moved up one line, if the text was scrolled up to the limit. Subsequently entered keys show that the cursor position did not change but the caret is displayed at the wrong position.

[Vidar Hasfjord]

Hi @elotter,

I just tested the status of this issue, and it is still an issue on both branches/7-coolprj-dev and on the trunk. It seems it may have something to do with the order of scroll and caret position updates, since it happens when the editor has to pull in preceding lines to fill the window with the last page of text.

To reproduce:

1. Open a large file, e.g. "cooledit.cpp".
2. Scroll to the bottom, e.g. by pressing Ctrl+End.
3. Without scrolling, move the cursor to the end of the preceding line, e.g. by pressing Up Arrow, End.
4. Delete the end of the line by pressing Delete.

Observations: The line below is combined with the current line, as expected. However, rather than the line below being pulled up, as normally would be expected, the edited line is pushed one line down, and the preceding lines are pulled down from above to fill the window. This is fine and makes sense, since we are at the end of the scroll range. But, erroneously, the caret stays put, rather than follow the edited line. Moving the cursor, e.g. by pressing Arrow Right, corrects the caret position.

PS. Interestingly, Visual Studio does not pull in lines from above in this case; it just lets the bottom of the window fill with empty space. Same for WordPad. However, Notepad behaves like TCoolEdit and pulls in lines from above to fill the window (but adjusts the caret correctly).

[Erwin Lotter]

This bug has been fixed with [r8139] in branches/7-coolprj-dev.
A call to ScrollToCaret is needed when the caret changes its position due to e.g. vertical scrolling.

The unexpected scrolling can be avoided by simply not calling AdjustScroller() as was already the case in DeleteWord(). This however will prevent the adjustment of the scrollbar size. So I'm looking for the proper way to prevent this scrolling.

[Vidar Hasfjord]

Hi @elotter, I have applied a minimal fix for this issue on the trunk [r8177]:

I just added a call to SetCursorPos in DeleteChar, similar to DeleteWord, so that the cursor position is properly updated. Of course, both functions continue to behave like Notepad (pulling text down from above to fill the last page), but that is fine, I think. For now, I prefer the simplicity of the fix. It is also consistent with the scrollbar.

[Erwin Lotter]

In [r8141] I introduced a (hopefully clean) method to adjust the scrolling behaviour on the last text page.

[Vidar Hasfjord]

In [r8141] I introduced a (hopefully clean) method to adjust the scrolling behaviour on the last text page.

Promising, if you prefer the Visual Studio behaviour (I find the Notepad behaviour acceptable, though). However, you should include the whitespace below the last line (now allowed on the last page) in the calculation of the scrollbar range (otherwise the scrolling jumps abruptly when you click on the scroll bar thumb).

[Erwin Lotter]

However, you should include the whitespace below the last line (now allowed on the last page) in the calculation of the scrollbar range

I did so in [r8202] and [r8203]. Please test.

[Vidar Hasfjord]

Please test.

I've tested a little, and it seems to work; the scrollbar adapts. But I was surprised by the smart behaviour. I envisaged a simple addition of (almost) a screen-full of lines to the scroll range always (this is how Visual Studio works), but instead your implementation smartly adapts the amount of extra scroll range (whitespace) to the editing actions; i.e. if you merge/delete lines at the end of the file, whitespace and scroll range is added, but if you then append lines the extra white space and scroll range is reduced until the last line is at the bottom of the window and the end of the scroll range. Pretty clever, and the code doesn't look overly complex either. Nice!

[Erwin Lotter]

Fine. Hopefully it works out.

I envisaged a simple addition of (almost) a screen-full of lines to the scroll range always (this is how Visual Studio works), ...

If I got right what you mean, VS seems to have changed it's behavior. My version (17.14.7) adjusts the scroll range smoothly. (But beware of upgrading. The search function no longer works reliably. In particular, 'Rename' (^R ^R) no longer finds all occurrences.)

[Vidar Hasfjord]

I noticed that mouse scroll-wheel and touch scrolling has a different scroll range than the scrollbar. With the scroll-wheel you can always scroll the last line to the top of the window, i.e. you always have (almost) a screen-full of extra scroll range (similar to Visual Studio).

Not much of an issue, but why the difference? Now, if you use the scroll-wheel to scroll the last line to the top, then click on the scroll bar thumb, there is that jarring abrupt jump.

[Vidar Hasfjord]

[VS] adjusts the scroll range smoothly.

Maybe I was unclear. Yes, the scroll range is adjusted smoothly (i.e. with any change to the number of lines in the document). But the scroll range always includes an extra (n - 1) lines of whitespace below the last line, where n is the height of the client window in number of lines. And whatever scrolling method you use (mouse, touch/touchpad, scrollbar, keyboard) the scroll range is the same; the last line can always be scrolled to the top of the window.

[Erwin Lotter]

Not much of an issue, but why the difference?

This is because part of the scrolling is done via TCoolTextWnd, where I apply the ScrollBackMinimumLines setting, while wheel scrolling is done directly via TCoolScroller, where I only ensure that at least the last line remains visible. This isn't entirely consistent yet; I'll have to revisit it once the bug with the missing scrollbar ([bugs:#623] is fixed.