So I dug up a post where it was explained:
This means that if click-to-scroll was still implemented, I'd have to choose between one of two behaviours:
- The view is scrolled to the text in the minimap that you clicked on. This would result in the orange view port representation _not_ moving to where you click, which would likely be unexpected.
- The view port is scrolled to where you click. This would result in in the text you clicked on in the minimap _not_ being the text you now see in the main view, which would also be unexpected.
It is my opinion that the first behavior is a hell of a lot more unexpected than the second one. Who cares if the highlighted area moves less than you expected it to? We want to go to where we click, not go to some place we can't see.
I know this is really super-nitpicky, but the quality of Sublime is so high already as it is that the only things left to deal with are these nitpicky issues. And this one's beginning to bother me a whole lot.
The only use case (that I do admit I do occasionally, since I can't use it the other way) is to scroll around a document quickly across the entire document by scrubbing the minimap.
BUT I believe there is a way to reconcile this in such a way that **only if you drag** does it treat the vertical space as the full document. If you do a quick click on an area outside, it should definitely take you to where it was clicked. Repeating clicks in this fashion will let the highlight-block eventually reach that position after all. So which behavior it takes should depend on whether the click lands on the highlight or not. No Ctrl+click or right-click or any madness like that.
This will be reminiscent of scrollbar functionality which does page-up or page-down when clicking in the empty regions, except we have visual feedback and control. It's actually perfect.