GTK gets this right, and Qt does not.
1. You're editing text outside of Emacs. Your cursor remains where it was, so you insert a single character and the document scrolls back to the cursor. You can then delete that character.
2. You're editing text in Emacs. You like to pretend it's still the 1970s and off-screen cursors are some pie-in-the-sky fantasy. You solve the problem with some unspecified ELISP wizardry, which as a self-respecting Emacs user you are surely capable of.
3. You're reading a read-only document. You activate your full-text search, which every good document viewer has, and start typing the last sentence you read while it's still fresh in your memory.
Double hell no. The majority of the time it's a log file with lots of repetitive lines, and I'm definitely NOT going to remember exactly the line, especially after the disruption of accidentally jumping somewhere unexpected.
Click in the scroll bar to
(•) Jump to the next page
( ) Jump to the spot that's clicked
For scroll ranges that aren’t overly long, you can long-press so that the area ends up scrolling to that position. Only for long scroll ranges is it necessary to drag, use the context menu, or the Shift key, for absolute positioning.
There are certainly trade-offs, but it’s not like there aren’t justified reasons for the way it is.
I've never found it of any use.
> and Qt does not.
Isn't that what middle click does in Qt?
pgup behaviour allows for intermediate speed when line-by-line is too slow, while dragging is imprecise
That's two actions, while clicking is only one.