Code is read a lot, and sometimes you read it, while you edit it. To edit, you use some selections. Then you decide to just briefly check the surroundings again, maybe through <pagedown> or through mousing, only to find that this destroyed your carefully chosen selection, or dropped some, without you anticipating it. Also, mouse scrolling stops working under unintelligible conditions.
Now, view mode was supposed to aid with that, but it turns out to be part of the problem. For one, it doesn’t doesn’t know about the mouse or <pagedown> (which is weird), nor does it know about searching, which, arguably, meets the “view changing” use case “scroll to where X is” more often than the “moving is selecting” use case “select next X”. Secondly, you can’t scroll past the cursor upwards, while downwards unintuitively works but causes selections to be truncated or dropped when you scroll past them.
I suggest “moving is not selecting in view mode”: have
-
<pagedown>and mouse scrolling imply a locked view mode once more than a screenful of text is scrolled (and to leave selections untouched) - view mode support searching
- view mode allow the main cursor to not be on the screen
- view mode leave selections untouched
- it possible to leave view mode in different ways:
- return to the previos cursor position, restoring selections
- drop selecions (adding them to jump list), and move cursor to 0,0 of current screenful of text
For now you need to work around that by wrapping movement with Z and z when selections are to be preserved, which is easy enough, but has the downside of overwriting what you had in "^. This again can be mitigated by choosing an arbitrary register for the marks, but this is unintuitive and cumbersome.
I’d write a plugin (if I knew how to), but I think this is something almost everyone would want.