13
2
Is it possible to get smooth scrolling (using the mouse scroll wheel or macbook touchpad) within a terminal on Mac OSX (Lion)? Furthermore, could I do this within vim?
I find that smooth scrolling aids the reading of code, I don't like it when you can only scroll in discrete lines as opposed to continuous pixel-by-pixel scrolling.
Thanks
Eddy
Posted 2011-11-13T16:02:14.400
Reputation: 2 897
5
I'm using iterm2, and I'm finding very nice functionality using vim 7.3 in the terminal with the following options:
set mouse=niv #or set mouse=a
set clipboard=unnamed
EDIT: set mouse=a also seems cool to use as indicated by the other suggestion.
What this does is automatically switches you into either visual mode from normal while selecting text, or into the mode that says -- (insert) VISUAL -- from insert mode. This also has the handy advantage over not setting these modes at all in that when you've got line numbers or relative line numbers, it'll go ahead and copy those numbers you likely don't want to copy. When it drops you into mouse-enabled visual mode this way, it avoids copying those line numbers, as it works to control the visual mode selection rather than the native terminal's selection (which gets suppressed). Scrolling works just fine throughout, keeping in mind that it selects everything from where you had started the selection to the bottom of the screen. Forget about ctrl+c/ctrl+v in vim - You use the vim yankypasta commands (y, yy, p, etc) to copy to the system clipboard:
http://vim.wikia.com/wiki/Mac_OS_X_clipboard_sharing#Comments
Again, iterm2 -- osx's built in terminal is trash. I don't really see your beef with line-by-line scrolling, as I'm happy with how this simply functions as vim should, but maybe it's for similar reasons to why I can't watch other people play video games out of motion sickness or why flourescent light and CRT monitor flicker messes with people's heads to the point of migraine. Try adjusting the refresh rate on your brain, you can feel the knob if you press into your temple hard enough and turn.
Dmitri DB
Posted 2011-11-13T16:02:14.400
Reputation: 323
0
I don't really agree with you but here is a Terminal.app plugin that does what you want and more.
You might need to add
set mouse=a
to your .vimrc. See :help mouse for more info.
romainl
Posted 2011-11-13T16:02:14.400
Reputation: 19 227
Unfortunately the plugin requires SIMBL, which isn't available for Lion – Eddy – 2011-11-14T20:48:57.230
I didn't know because I don't have Lion. MouseTerm is the only way to add mouse scrolling to Terminal.app I've ever heard of. It appears that some people have reported limited success in using SIMBL on Lion, did you try? Also I see that iTerm2 provides "mouse reporting" and scrolling but it will probably scroll line by line. As a side note I hardly scroll (up/down/j/k) anymore: I find /, ?, fF, tT and <C-f>/<C-b> a lot more useful.
Note that these make the mouse-wheel scrolling work, but they don’t address the primary issue: “I don't like it when you can only scroll in discrete lines as opposed to continuous pixel-by-pixel scrolling.” – Chris Page – 2012-07-20T06:21:21.430
This type of scrolling (line by line) is hardcoded in Vim. There's thankfully no way around it. If one really needs it one should insist on it with carefully worded arguments on vim-dev or provide a patch.
– romainl – 2012-07-20T07:08:22.203The reason why I want smooth scrolling is that I tend to lose my place when scrolling through lines discretely. It's hard to explain. Maybe it doesn't effect everyone but it does for me – Eddy – 2012-07-20T09:07:48.627
You may have a better experience if you use a Vim application instead of using it within a terminal session (http://code.google.com/p/macvim/, http://macvim.org/OSX/). Is there a reason you need to use it within a terminal?
– Chris Page – 2012-07-20T06:20:05.6733MacVim doesn't provide smooth scrolling either. – romainl – 2012-07-20T07:08:53.237
Hi @romainl. I wonder how vim behaves if the buffer size (windows size) is really big (i.e. the size of the whole file). GOtta test this out. Then we could put a vim buffer inside a smooth scrolling GTK (or QT) widget and scroll the entire vim buffer inside the widget smoothly. This would have the added benefit that the cursor could be easily hidden like with modern editors. When the user moves the cursor, the widget would know (using the same API gVim uses) and recenter the scroll position accordingly. – trusktr – 2013-10-13T16:38:19.057
(cont'd.) Window splitting could even be accomplished by duplicating vim's full-file-length output into a new widget and scrolling the widget smoothly to the appropriate position. This would all require some simple arithmetic and good knowledge of a nice widget toolkit. Window splitting (horizontal and vertical) and scrolling and resizing the widgets would be the. The rest would be a piece of cake to do (menus, tabs, things that gVim and qVim already do). – trusktr – 2013-10-13T17:37:36.327
(cont'd.) This has the potential to vastly improve vim's performance too. Think about this: every time you scroll the console vim or g/qvim windows (currently), vim has to rewrite almost every character on the screen. If the vim buffer was full length, and scrolling was handled independently by a smooth-scrolling widget, vim would only need to update one line's worth of characters at a time whenever you move the cursor to a new line (or better yet, a single character when you move forward or backward one character). This would be a HUGE performance advantage for vim! – trusktr – 2013-10-13T17:44:10.527
(cont'd.) On the other hand, there may be plugins that rely on what's visible in the window (EasyMotion, for example, that updates the view to show you movement suggestions) and such plugins might have to do more calculations on the full length of the text when invoked. Another such example would be Signify, which would have to show git diffs in the gutter of the entire full length text (but that case probably wouldn't be too bad because Signify only uses two columns maximum, and only the rows that have changes). – trusktr – 2013-10-13T17:44:33.653
(cont'd.) Lastly, but probably only the beginning, modern scrollable container widgets (like the ones in GTK3 or Qt) support inertial scrolling. Imagine being able to swipe vim with your finger and scroll it smoothly with inertia. Imagine pressing pageup or pagedown and the scrolling is animated with acceleration and deceleration. – trusktr – 2013-10-13T17:50:27.573
Oh, I forgot to mention, and if you you haven't pieced it together already: these smooth animations I speak of would be pixel by pixel, not line by line. #:^) – trusktr – 2013-10-13T17:52:58.130
@trusktr, your idea sounds good, at least superficially, but redrawing is not the only reason why scrolling is jerky in Vim. Syntax scripts (and the underlying regex engine) are quite slow too and cutting the buffer in smaller slices is also a way to make syntax highlighting more usable. Somehow I doubt Vim would be able to open a 5000 LOC PHP file as quickly as it does now if it had to deal with all of it. – romainl – 2013-10-13T19:42:05.413
@romainl Yeah, syntax scripts seems like they could cause slow loads running on 5000 LOC. This'll be interesting to test. – trusktr – 2013-10-17T19:11:55.223
Another small (possibly negligible for some) advantage of using scrollable widgets would be that you could render a small mini-buffer similar to how Sublime does. – trusktr – 2013-10-17T20:05:43.320