OBSERVED RESULT Selecting the whole document with "Ctrl+A" shortcut, scrolls down document to the bottom. EXPECTED RESULT Selecting whole text in opened document should not move cursor and view to the bottom of the document, instead it should stay on line observed before invoking "Ctrl+A" shortcut.
Can confirm, because the cursor gets moved to the end of the selection. This is a general KTextEditor behavior. Maybe it should be re-thought, or automatic selection actions shouldn't scroll the view.
That currently is by design indeed due to the cursor movement. Personally, when we changed to this behavior, I also disliked this. But at the same time it's also deterministic - simply the behavior right now. It's not even a bug, rather a wish to change behavior.
Created attachment 145058 [details] myutils.js As a workaround you can place the attached script as ~/.local/share/katepart5/script/commands/myutils.js and then create/reassign shortcut for "select all text" in GUI.
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/ktexteditor/-/merge_requests/248
It was decided that the current behaviour is intentional. See the linked MR for details.
OK then. Sorry I wasted everyone's time. I guess this is "works for me" situation, since the provided workaround is easy to implement. But, just for the record, IMHO: - I have never encounter text/code/word editor that scroll view to the end on "select all", and I see no benefit of such behavior (TBH never used new QtCreator 6, but I'm confident that's a regression from 5 on their behalf) - The considerations of insertion point placement are irrelevant here, since there is no purpose to type or paste on "selected all" - The workaround have added functionality. You can easily use (as a cross-app consensus) left/right arrows to cancel selection and move to begin/end. Also up/down arrows to move in the current view (no mouse involved). As a silver lining, users can now found solution if annoyed/involved enough, and maybe learn the power of Katepart scripting at the same time. Cheers!
Hi, not really a "works for me" I think since that'd apply if this was a bug. Anyhow, the reason I linked the MR is that if you have really believe that this is an improvement and have a solid argument, you can add a comment there. This is how KDE grows (and I guess that's why we have so many options ;)). For me, it didn't matter either ways but maybe others really have a usecase for this that we didn't see.
(In reply to Waqar Ahmed from comment #7) Hey, thanks for all your effort. Since I'm not a developer, that's way over my head. Never thought this so controversial though, and hope @Dominic finds that discussion, really curious to hear the arguments. Anyway, scripting is far as I go and KDE grows in other directions, too =). Thanks again
Git commit 116dc5c4e43f2e2be08ad0bf3c10e8df2d0906bd by Christoph Cullmann, on behalf of Waqar Ahmed. Committed on 24/01/2022 at 19:07. Pushed by cullmann into branch 'master'. Don't scroll on select all Tried Qtcreator, browsers etc. No one jumps to end. We use setSelection here to ensure we don't scroll anywhere The cursor stays in place i.e., it doesn't move to end of selection that is okay and expected. The idea here is to maintain scroll position in case select all was mistakenly triggered, and also to if you just want to copy text, there is no need to scroll anywhere. M +8 -2 src/view/kateview.cpp https://invent.kde.org/frameworks/ktexteditor/commit/116dc5c4e43f2e2be08ad0bf3c10e8df2d0906bd
We made the change after rethinking the use cases, thanks for bringing it up.