macvim-dev
Pixel by pixel scroll.
MacVim still only scrolls line by line. The scrolling on Mac should scroll individual pixels. (The Emacs Mac port does this fwiw), and IIRC Bjorn made progress towards this but abandoned the effort.
I don't see what's to be gained here. AFAIK Vim always has to show whole lines at all times. At best, this would be for when scrolling using the mouse/trackpad, and then it would at best be purely eye candy; you wouldn't be able to stop a scroll with e.g., only half the pixels of the top line showing.
And as far as eye candy goes, the scrolling looks awfully smooth to me as it is. Maybe if one's scroll speed is set to "really slow" it would look choppy.
At best, this would be for when scrolling using the mouse/trackpad
People would also use this via keyboard shortcuts (I would, and I do in other editors).
and then it would at best be purely eye candy;
I don't think it's purely eye candy. There's real productivity wins as well, when the scroll view is slowing down with a proper pixel based easing function, you can make sense of some of the content before it reaches a complete stop (whether or not you use trackpad or keyboard driven animated scrolls). But as it is, when it's slowing down, it jerks around a couple of times, which is jarring and makes it impossible to use that window of time to make sense of the content.
(Pixels aside, in general, animated navigation is super helpful because it lets you track blocks of code when scrolling up/down large amounts).
you wouldn't be able to stop a scroll with e.g., only half the pixels of the top line showing.
Correct. iOS (and Mac?) have many pixel based animations that have "snap points" - never being allowed to come to a rest in between.
And as far as eye candy goes, the scrolling looks awfully smooth to me as it is. Maybe if one's scroll speed is set to "really slow" it would look choppy.
You don't notice any line/line movement when moving fast, (because each animation frames typically cause movement further than a single line), but watch the end of the scrolling where it would normally be moving very slowly. You can definitely see the dropped positions (with you eyes alone, but use your iPhone's slowmo camera to confirm). (Imagine if your mobile apps or web pages had the same behavior).
but watch the end of the scrolling where it would normally be moving very slowly.
Why would it be moving slowly? Are you talking about the Lion-and-up "scroll inertia"? I have that disabled, because it's annoying to me.
animated navigation is super helpful because it lets you track blocks of code when scrolling up/down large amounts
I can track blocks of code when thus scrolling without animated navigation. (Or, perhaps I just don't understand what "animated navigation" refers to in this context.) If I open a large file in MacVim (or regular Vim) and hold down Ctrl-E, I have no problem visually tracking blocks of text as they flow by. And my keyboard repeat rate is cranked up as high as the slider allows. I don't use the mouse at all in MacVim, because pretty much the whole point of Vim (as opposed to a "traditional" GUI editor) is to not use the mouse.
Anyway, if Vim itself is incapable of showing partial lines, this is all moot.
Is the hesitation that you feel that scroll animations in general are fundamentally broken, or that they don't belong in a text editor, or that they don't belong in MacVim?
Why would it be moving slowly? Are you talking about the Lion-and-up "scroll inertia"? I have that disabled, because it's annoying to me.
(I'm not talking about the Lion down-means-up, and up-means-down "feature"). I am talking about scroll animations in all Mac operating systems since 2007, which occurs in all scroll views by default including web pages, table views etc. It's where you swipe and release, and over several animation frames, the content slides around according to some physically modeled easing function. I don't think it's even possible to disable this and I've never met anyone that wanted to.
I can track blocks of code when thus scrolling without animated navigation. (Or, perhaps I just don't understand what "animated navigation" refers to in this context.)
But I and many people wish to go even faster than the key repeat rate. In fact, I want to scroll so fast that a key repeat rate that would be required using ctrl-e would be highly unusable for anything but driving the scroll. At certain velocities, a single screen vsync would have to consume several key events to drive a scroll that fast (which I'm not even sure is possible). Yet at the same time, I want to see the content fly by in as incremental of a manner as the screen refresh rate will allow - because that visual information is useful. Even if at higher velocities where it's difficult to make out detail - I can tell a lot by the general shape/syntax color of the text. Scrolling animations (trackpad driven or even keyboard) is an excellent interaction for accomplishing this experience, which is why MacVim does make some attempt to emulate this.. I've never heard anyone object to scroll animations in general, and MacVim already has them. This github issue tracks something more specific though - fixing the discontinuities that currently occur in MacVim's final frames of that animation that it already has - which would require moving the animation on a per pixel basis vs. per line.
Anyway, if Vim itself is incapable of showing partial lines, this is all moot.
Here's Bjorn's original work towards this: https://twitter.com/b4winckler/status/114007946601562112
I'm sure it's not easy, but I suspect it's possible and maybe even feasible? I'm not sure how one would accomplish it though, but I have some wild thoughts. Maybe we could dig up Bjorn's original patch and try to revive it?
(I'm not talking about the Lion down-means-up, and up-means-down "feature")
I'm not either. That's "natural" scrolling, not "inertia".
It's where you swipe and release, and over several animation frames, the content slides around according to some physically modeled easing function.
I don't know what that means, and consequently I'm still not totally sure what you're talking about. Does it mean that even after you release the swipe, the content continues to slide around for a bit before stopping? That has been complained about, and is most certainly disable-able, as I see no such behavior because it's annoying and I turned it off. I think that's called "inertia" (that's what TinkerTool calls it anyway), and it was not there (at least by default) until Lion IIRC. You can disable it with TinkerTool or with a defaults write command or combination of them (I think it gets called some variation on "MomentumScroll" there, like in defaults write -g AppleMomentumScrollSupported -bool false). It makes scrolling hard to control.
Is the hesitation that you feel that scroll animations in general are fundamentally broken, or that they don't belong in a text editor, or that they don't belong in MacVim?
My hesitation is (insofar as I understand what's being proposed, which I'm not sure that I do) that such a feature (a) does not belong in (plain) Vim, (b) cannot be made to be in plain Vim without mucking about with plain Vim, (c) consequently it cannot be made to be in MacVim without mucking about with plain Vim, and (d) therefore it should not be made to be in MacVim even if it's possible.
Regarding when the "inertia" was introduced, I might be confusing it with a different scroll-related annoyance, namely the "rubber band" effect, which only arrived with Lion IIRC.
FWIW, I think doing this in MacVim is possible (naturally, as an opt-in feature); both text rendering (CoreText and legacy) views currently manually implement scrolling rather than use the standard Cocoa primitives to do so. That presents some challenge. So, too, does how we interoperate with core vim; we send messages back and forth regarding what lines are visible or not, and (try to do) very precise, controlled redraws of only things that changed. Adjusting that would be trickier, as now we'd need to be "pretending" our view was larger than it was so core vim will send us more lines than we need, we'd need extra messages probably to understand the full length of the scrollable content better. Our resizing also does a lot of special-case hackery to constrain itself to row/column multipliers (which is already a source of lots of bugs) which would need revisiting. The upshot is that this is going to be a lot of work, especially if one is going to support it for both renderers.
I'd really love to rewrite and simplify our renderer so its easier to adopt "high level GUI" features like this. But that is even more work, and there are good reasons MacVim originally took the approach it did, likely related to performance on older machines, that I'm loathe to screw around with because I have no capability to evaluate the impact of or test how it would behave on older systems.
No worries about older systems and the current renderers. MacVim can have yet another "sophisticated" renderer, like using Metal. Well, it should follow the current APIs though.
So how difficult would this be? How many hours would it take? Is it worth getting a bounty-source together for it?
@splhack Do you think this is something that could be done in approximately a couple of solid days' worth of work? Note, the pixel by pixel scroll is only really needed at the start/end of the scroll. During the main portion of the scroll animation, it travels fast enough to not need per pixel level scrolling - the effect is still smooth during that portion of the animation.
I was thinking it could even be hacked by asking vim for a layout of all the windows (perhaps winsave), and knowing various settings such as cmdheight. When scrolling, you could detect, before an actual full line's worth of text is scrolled, which pane it is in, and preemptively translate that layer just for that vim window, in the correct direction. Then when scrolling at a full line's worth, you'd perform an actual Vim scroll by one line, allowing Vim to update the window with the new line's content, and the translated buffer could then be updated with that new line (repainting/shifting all the contents by one line's height to make room).
I'm asking how much work this would take to pull it off with good performance because I want to set up a bounty source for it.
I don't think it's a "couple of days." I'd say it's a "couple of weeks." I'm skeptical that your proposed hack would work well enough to be something we'd be comfortable shipping (c.f. the ligatures support, which seemed fairly simple on the surface but has turned out to cause quite a few unexpected side-effects).
(c.f. the ligatures support, which seemed fairly simple on the surface but has turned out to cause quite a few unexpected side-effects).
Off topic, but ligatures have been amazing in MacVim! Sorry if that's not relevant, but I just have to say, it really puts MacVim above the rest IMHO. Pixel by pixel scrolling might be another one of those things that's tricky but worth it.
Maybe we can put together a bounty/kickstarter after you or someone else does some deeper investigation of the options, including whether or not my suggested hack would be viable. I know some other people that would be interested in contributing to a bounty to make it happen.
FWIW I like all the default new OS X scrolling - inertia, reverse scroll, rubber band. And to me the whole point of MacVim is better system integration - mouse, keyboard, UI, UX etc. For those who prefer the standard Vim way, is there an advantage to MacVim over standard?
That said, this does sound like a pretty big feature and one where it must be implemented perfectly to feel native, otherwise it will just be jarring. I've "put up with" the line scrolling fine until now so it doesn't seem essential, just nice to have.
