Mini-map clicks going to wrong location in file?

[adr]

Hi, I've just started playing with Sublime Text 2 and although I can see the mini-map being a really useful feature for me, it doesn't seem to work as I expect. If I click and drag on it, then it shows the appropriate areas of the file as I move around. But if I simply left-click an area of the map (outside the current highlighted area) to jump directly to it, then it never repositions itself to show the point in the file that I wanted to jump to. Instead it always seems to go way past it and it's quite annoying! Is it possible I've misconfigured something? I don't remember changing any settings that would affect the mini-map though...

I'm using beta build 2181 if that helps.

[MikeC]

This comes up a lot. I agree that the current behaviour is borked, as do a lot of people, but it's not the no-brainer fix it appears to be. What was less obvious (to me, anyway) is that if ST *did* show the actual point in the file that you'd clicked on, the mouse would no longer be over it in the minimap, because the minimap would have scrolled.

AFAICS the options are:

a) Live with the mouse being out of step in minimap

b) Don't scroll the minimap on click

c) Use SetCursorPos or similar to move the mouse to the correct minimap position

None of those is perfect, or obviously the lesser evil.

[adr]

Sorry, I don't understand... this behaviour is by design?? What's wrong with having the mouse be in the wrong place after clicking the map? If I'm doing that (as opposed to dragging the highlight around) then all I want to do is to jump to that point in the file, not continue using the map afterwards. As long as the map itself scrolls and highlights the new position correctly I couldn't care less where the mouse pointer ends up relative to it, it's easy to reposition based on the new highlight location if you want to click again.

c) Use SetCursorPos or similar to move the mouse to the correct minimap position

So is it possible for this behaviour to be modified/overridden somehow? If so I'd like to try doing that myself because it's making the mini-map much less helpful than it really should be!

[MikeC]

So is it possible for this behaviour to be modified/overridden somehow?

Not as far as I know. SetCursorPos is a Win32 function that repositions the mouse cursor; it's not part of ST's Python API.

[adr]

Thanks for the info Mike... I'm utterly astonished at this! The mini-map seems to be a 'flagship' feature of ST given that it's highlighted on the frontpage of sublimetext.com. It's certainly a standout feature in the screenshots that helped convince me to try ST. So for it to operate so unintuitively is simply crazy. It's like clicking a list widget and having it consistently select an item much further up/down the list from the one you wanted. Disorientating *and* annoying. Maybe there actually people who prefer this wacky behaviour but surely there could at least be an *option* to have it behave sensibly?

[alexrussell]

The issue you specifically are having on happens on files whose minimap-height is greater than that of the available minimap area, so it's not all files, but yes, a good number. (For me, if a file goes over about 500 lines.)

But on to your suggestion of making it behave sensibly, the problem is that there's no 'sensible' that works for everyone. For some people, your method whereby a single click works as expected will actually behaving erratically because they're click-draggers. As soon as you start dragging (using your 'sensible' option) the mouse will be in the wrong place thus the editor will jump around. The only solution to that is to use the SetCursorPos Win32 API as MikeC suggested, but as he said it's going to have to be built into the ST2 core. Also it may not be cross-platform compatible: I know Win32 has the function, but maybe other OSes don't allow applications to change the cursor position programmatically. While it seems crazy for an OS not to allow applications to do this, you can see how they may wish to lock this down - it creates a bad user experience if the cursor is not where you last left it! And anyway, even if this was possible, some may still call it broken (or not 'sensible') due to this exact user experience breaking: "I click the minimap and it moves my mouse around. What's that all about?"

But having said that, as MikeC said you have a lot of people with you thinking the exact same thing. The bigger issue is how to fix it without making the situation worse or just as bad.

[adr]

The issue you specifically are having on happens on files whose minimap-height is greater than that of the available minimap area, so it's not all files, but yes, a good number. (For me, if a file goes over about 500 lines.)

That's true, but unfortunately the mini-map is most useful for exactly those files which have several hundred lines or more!

But on to your suggestion of making it behave sensibly, the problem is that there's no 'sensible' that works for everyone. For some people, your method whereby a single click works as expected will actually behaving erratically because they're click-draggers. As soon as you start dragging (using your 'sensible' option) the mouse will be in the wrong place thus the editor will jump around. The only solution to that is to use the SetCursorPos Win32 API as MikeC suggested, but as he said it's going to have to be built into the ST2 core. Also it may not be cross-platform compatible: I know Win32 has the function, but maybe other OSes don't allow applications to change the cursor position programmatically. While it seems crazy for an OS not to allow applications to do this, you can see how they may wish to lock this down - it creates a bad user experience if the cursor is not where you last left it! And anyway, even if this was possible, some may still call it broken (or not 'sensible') due to this exact user experience breaking: "I click the minimap and it moves my mouse around. What's that all about?"

I still don't understand why we're talking about SetCursorPos... I entirely agree that the application controlling the mouse pointer is a horrible idea, but why do both you and Mike think is it necessary to raise this point? Unless I'm missing something really obvious there's no reason why the existing click-drag wouldn't continue to work exactly as it does now (which I have no issues with at all, it's perfect!). OK, if you do a single-click and it jumps directly to that point in the file, the mouse pointer may not be over that location in the mini-map... but so what?? You'll be able to see the area of the file itself in the main part of the window *and* the mini-map highlight will reflect the new location. If you want to perform a subsequent single-click then the effort required to look at the updated mini-map and reposition the mouse is trivial! Certainly far less annoying than not getting the location in the file you wanted in the first place!

But having said that, as MikeC said you have a lot of people with you thinking the exact same thing. The bigger issue is how to fix it without making the situation worse or just as bad.

I'm not advocating the removal of the existing functionality, I don't understand why people like it but I have no problem with leaving it there. All I'd want is an *option* to have the single-click behaviour do something reasonable In the meantime I'm trying to train myself to click-drag every time, at least that works as I expect it to.

[MikeC]

I suppose another option, which I haven't seen suggested yet, would be to abandon constant scaling and instead squish the minimap vertically as much as necessary to ensure that it *does* fit in a single screen without scrolling. Then the problem would never arise.

Ugly, though.

[alexrussell]

Man, I really hate that this forum doesn't do post subscription!

I still don't understand why we're talking about SetCursorPos... I entirely agree that the application controlling the mouse pointer is a horrible idea, but why do both you and Mike think is it necessary to raise this point? Unless I'm missing something really obvious there's no reason why the existing click-drag wouldn't continue to work exactly as it does now (which I have no issues with at all, it's perfect!). OK, if you do a single-click and it jumps directly to that point in the file, the mouse pointer may not be over that location in the mini-map... but so what?? You'll be able to see the area of the file itself in the main part of the window *and* the mini-map highlight will reflect the new location. If you want to perform a subsequent single-click then the effort required to look at the updated mini-map and reposition the mouse is trivial! Certainly far less annoying than not getting the location in the file you wanted in the first place!

SetCursorPos was only brought up as a way to fix/unify the single-clickers' and the click-draggers' user experience. If your single-clicking method were to be brought in, anyone who click-drags will notice the weirdness (first it goes to the right place, then it's off), and similarly if the current method is employed it'll "work" for click-draggers (okay still not go to the right place, but at least will be consistent) and not work for single-clickers. The SetCursorPos idea works for both, but involves moving the mouse cursor programmatically which I think we're all agreeing is odd at best.


I think MikeC's idea of squishing isn't too bad. As he says, it's a bit ugly (would it just vertically compress or maintain aspect ratio, maybe use a liquid rescale-type method - but then the minimap doesn't truly reflect the buffer's contents).

[adzenith]

There's a userecho feature request that I think would solve a lot of problems:
http://sublimetext.userecho.com/topic/7 ... ouse-over/
I also mentioned it in an older thread similar to this one:
viewtopic.php?f=3&t=3414#p16419