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.
Best Answer
Not without hacking less's source code. A bit of background story:
Less cannot handle mouse (including scroll events) at all.
Terminal emulators support a so-called alternate screen. This is which most fullscreen apps switch to for their duration (and switch back to the normal screen when they quit, causing the previous contents to "restore"), and it doesn't have a scrollback buffer. Less also switches to this alternate screen, unless
-X
is given in which case it doesn't.Many terminal emulators figured out that when it's in alternate screen mode and the application running inside is not interested in mouse events, it makes sense to convert scrolling into Up or Down keypress events. It's a hack, and it'd be harmful either on normal screen (imagine what would happen e.g. at your shell prompt), or when the application wishes to handle mouse (sure, they have to see the actual mouse events then). But since by default neither of these two hold when you're running
less
, this hack kicks in (subject to the terminal emulator supporting it, and being enabled via\e[?1007h
vs.\e[?1007l
). Your scroll events are converted by the terminal emulator to Up and Down keypresses, and less can't distinguish them from actual keypresses. It doesn't receive mouse scroll events: it sees Up and Down keypresses.So there you are: Either you switch to alternate screen and the terminal's hack converts scroll events into keypresses for less, and the normal screen is restored when you quit; or you don't, and then there can't be any magic converting scroll events to keypresses and less doesn't understand the scroll events.
So what could be done? Well, either implement mouse support in less and let it handle scroll events itself (and live with a nondefault click or copy-paste behavior), or implement another weird hack: upon quitting, after reverting to the normal screen,
less
could for the last time print a screenful of content, repeating whatever was displayed before you quit.In practice, it basically boils down to: sorry, forget it.