Sublime Forum

Mini-map clicks going to wrong location in file?

#1

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.

0 Likes
#2

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.

0 Likes
#3

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.

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!

0 Likes
#4

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.

0 Likes
#5

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?

0 Likes
#6

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.

0 Likes
#7

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

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!

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 :smile: In the meantime I’m trying to train myself to click-drag every time, at least that works as I expect it to.

0 Likes
#8

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.

0 Likes
#9

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

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).

0 Likes
#10

There’s a userecho feature request that I think would solve a lot of problems:
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

0 Likes
#11

Oh yeah, that’s genius. Hadn’t even thought of that! Fixes everything really. Still technically a broken UX when you first hover and the minimap jumps a little, but that’s a tiny price to pay for the benefit of all other perfectly-working UX.

Definite upvote from me.

0 Likes
#12

I’d love to see this feature as well. Second choice would be squishing the whole mini-map to fit vertically in the available area.

0 Likes
#13

Correct me if I’m wrong, but isn’t this the root problem: that when the user presses the mouse button down, you don’t yet know if they’re clicking or dragging? I don’t know about other OS’s but the Windows way of handling mouse messages is this for click events to be fired on mouse-up and drag-start events are fired when the mouse has moved n pixels from the original mouse-down pixel (where n==2 usually – the area marked by this radius is called “the slop”).

If you do this, a click could move the viewport to the code the user actually clicked on. Yes, the highlight may not be under the mouse anymore, but the user likely won’t care. If they’re dragging, you should scroll based on delta-y instead of abs(y) like you do currently if the user drags the highlight.

Here are a couple of other UX tweaks that might help:

  1. Invert the drag operation so that instead of dragging the highlight, you instead drag the code beneath the highlight; i.e. moving the mouse towards the bottom of the screen moves the viewport towards the top of the code. Currently the user drags the highlight, so dragging outside of the highlight doesn’t really make sense and that’s part of the problem we’re running into. If instead the user drags the code map then it’s easier to reason about what the right thing to do is.

  2. Animation would help. Instead of snapping to something, giving a 250ms, ease-out animation would make it much easier for the user to figure out what just happened.

0 Likes
#14

The current behavior in Sublime Text 2 is definitely broken. The point of the minimap is to find your place in longer files. If I look at the minimap and see where I want to go, clicking that place should take me there. Period.

I understand this means that after clicking my pointer would not be pointing at the text I clicked. That’s actually preferable: clicking again would then jump me further in the file. I could use that mechanism to quickly scroll in large files.

Please fix this!

0 Likes
#15

+1 for fixing this one. On mouse-up (and without any drag) it should jump directly at that line - this should be easy pixel / lines calculation, right?

0 Likes
#16

[quote]Build 2220
Improved minimap click behavior. The old behavior is available via the minimap_scroll_to_clicked_text setting[/quote]

Upgrade to the last Dev Build.

0 Likes