Francois 4 years ago • updated by Ewb 2 months ago 11
For large files, the displayed portion of the minimap doesn not cover the whole source. However, clicking on the minimap behaves just like clicking on the scrollarea: it moves the whole source to match the place that was clicked. That creates an inconsistent experience, since the portion of the code displayed in the main window is not the one I clicked on on the minimap.
Not sure if I make myself clear...

My suggestion would be to make the click on the minimap behave a little differently than the click on the scroll area, so that the portion of the minimap the user clicks on always become the portion of the code displayed in the main window.
Yes, when looking at a long file, if you recognize the area you want to go to in the minimap, clicking on that spot does not take you to that place in the file, which is disorienting.
It is very distracting when you click on an area in the thumbnail and insteat the editor scrolls to an entirely different position.

I suggest to let the minimap remain static on a normal click and only "scroll" when you drag the view on it. Dragging can be either using the current behaviour or like "from the new position". But I don't even really know how I imagine that myself.
Changing this behaviour might make it hard to jump around in a large file (maybe I want to click 1/2 way down and have it go jump to 1/2 way through the file.  Perhaps it could have both the current behaviour as well as your suggested behaviour.  A Ctrl-Click / Shift Click /Alt Click (pick one) would perform a jump relative to how far down on the document you clicked (current behaviour), whereas a single click would jump to the location of the actual text you clicked on.  For files where the entire contents fits in the minimap, these would act the same, and for larger ones the natural expectation of the document scrolling to where you clicked would be realized, but the current functionality still retained.
A solution could be to adjust the vertical scaling when a file gets too big to fit in the minimap in the normal scaling. Just squeeze it in, you'd easily spot this by the more dense line pattern. And this way you would always jump exactly to the part of the file you clicked on. Any downsides to this?
@Thomas.  Yes, two downsides.  1.  You could not jump to any recognizable section in a large file - it would be reduced to just pixels.  2.  If you wanted to quickly move down, say 10 pages worth, it would be impossible to judge how far this would be on the minimap, as it would be too squished for large files. 

"...you would always jump exactly to the part of the file you clicked on..."  Yes, and that part might as well be random, since it would be unrecognizable.
Ad 1. True, that might be a problem, although I might think that in a file that is that long, I cannot remember any recognizable parts anyways. :) Maybe when a file is that large, single lines don't count that much anymore in regards to recognizability, maybe it's more like chunks of lines anyway.

ad 2. I usually don't want to move down 10 pages but want to jump to a certain part in the file. If I'd do, I'd probably more easily use pgup/pgdown keys.

Anyways, being able to click on a location that I recognize and actually jumping to that location by clicking on it is something more useful to me than recognizing a section in a large document but then not being able to easily jump to it since clicking on it takes me somewhere completely different. Getting somewhere else than the code I clicked on in the minimap is just irritating, at least for me.
I agree with Francois. It would be very nice to actually go to the code that shows in the minimap when I click on it. And for jumping further up or down one could still click the scrollbar.

I agree with Francois, but some similar suggestions bring up some reasons why not to do this. However the new functionality decided, something needs to be done for files where minimap extends beyond visible area. Maybe as a compromise to some nay-sayers, what if the mouse action were broken into mouse-down and mouse-up. What if mouse-down (right-click or whatever if you don't like the standard behavior for large files) immediately moves the minimap shaded area (and file contents) down to where you mouse down (and actual scrollbar would move just slightly, of course, since it indicates the position in the whole file). Then on mouse-up after the click, the shaded area and the minimap slide back to be even with the scrollbar as it is now. In addition, if you find that you might have missed your target on mouse-down, you could hold the mouse down and drag a little to get to the right spot, but the speed of the drag would be relative to the number of lines displayed in your minimap area rather than your huge file, the minimap would still scroll a little as you drag, but not near as much as it does now. In other words, for huge files, dragging is almost impossible.. zipping at light speed, since it's tied to the actual scrollbar. When dragging past the displayed area, the shaded area would continue to scroll down (or up) at a reasonable speed (with the side to side jiggle speeding it up.. just like all other paced scrolling interfaces seem to do, such as when you're dragging down to highlight a long list of files in details view of the finder window, windows explorer, or whatever). This behavior would give the actual scrollbar a purpose, too, since it would be relative to the whole file rather than the subset view that the minimap would have.

Oh, I just saw Build 2220 addresses this somehow. I'll wait'll another stable release and give it a shot. :O)

2220 is pretty save to use, I've been using it ever since and never had a problem with it. Just FYI.

This behaviour seems to be implmented in Sublime 3