This is a problem that only happened to me since I've upgraded to Sierra. If I disable CoreText I can scoll fine (with the trackpad) but it is a bit slow. If I switch back to CoreText, I can scroll about 10 lines and as long as I keep moving my fingers, the scrolling suddenly stops. If I stop scrolling and scroll again, I can scroll some more. The amount of lines seems not to be consistent and increases after starting MacVim.
Interesting. I can't reproduce this. What version of MacVim do you have? I'm on MacVim 8.0 patch 8, and everything except non-native full screen is working fine.
I also have a scrolling issue ever since installing Sierra (MacVim 8.0 110, latest according to built-in autoupdater), sounds like it could be the same or similar - I narrowed mine down to some sort of sensitivity dead zone, i.e.: there is a clear threshold of finger speed on the trackpad - if I move my fingers faster than certain speed, it scrolls normally, otherwise it's not scrolling at all. No other apps are affected by this, also launched MacVim completely clean of my configs as per the debug instructions, but the issue persists.
I guess your description is actually a bit more exact, it's the same problem I meant. Moving fingers slowly does not move anything until a certain speed is reached which usually results in scrolling much more than intended. It actually occurs also when not using CoreText but it seems the velocity necessary is a little less. The stopping I mentioned before is happening when the movement is slower again. I'm using the current HEAD version.
Ah, yes, I forgot to mention in my previous comment - for me changing CoreText preference also doesn't seem to influence the issue too much, other than changing the rendering speed, so it's probably unrelated.
I have also just tested this with a fresh user account, created only for this and the issue is still there, so it's unlikely that it's a problem with config/plugin/user environment.
FWIW, I'm also having this problem. MacVim 8.0.3 on macOS Sierra
It seems this could be related to http://stackoverflow.com/a/39642552/974478 and other scrolling issues in third party applications that started to appear on sierra. In some cases scrolling gets very fast because more events are generated and the delta values are rounded to integer (jdk/swing). Others report that even in macOS' Terminal (which also scrolls only single lines), there is a minimum velocity now (http://apple.stackexchange.com/questions/254768/macos-sierra-scrolling-behavior-in-terminal-is-really-weird).
More digging: apparently NSEvent::deltaX is not the proper value, NSEvent::scrollingDeltaX is preferred (https://developer.apple.com/reference/appkit/nsevent/1524505-scrollingdeltax). But anyway, the frequency of events is too high, so I guess some have to be skipped if all movements should do something and vim only moves one line minimum. I've put together a simple patch with these changes and it solves the issue quite well for me: https://gist.github.com/kjyv/93bfe5e8b2e73ef7e76ceba8d33d6c2d
@kjyv could you send pull request?
Sure, #380
How about #381 ?
Ah, yes. It makes sense to also use hasPreciseScrollingDeltas. Looking at https://developer.apple.com/reference/appkit/nsevent/1525758-hasprecisescrollingdeltas, it says that it indicates the type of contents of scrollingDeltaX/Y, so maybe in both cases these values should be used? The scrolling behavior is fine for me, I didn't test it with a mouse wheel.
馃憤
will change to use scrollingDeltaX/Y in both cases on 10.7 or later.
updated #381
Most helpful comment
I also have a scrolling issue ever since installing Sierra (MacVim 8.0 110, latest according to built-in autoupdater), sounds like it could be the same or similar - I narrowed mine down to some sort of sensitivity dead zone, i.e.: there is a clear threshold of finger speed on the trackpad - if I move my fingers faster than certain speed, it scrolls normally, otherwise it's not scrolling at all. No other apps are affected by this, also launched MacVim completely clean of my configs as per the debug instructions, but the issue persists.