iTerm2:
Mouse reporting works out of the box, works in Vim, works fully in Tmux, mouse wheel reporting works in Vim and for navigating Tmux history, but mouse wheel reporting does not work in manpages, does not work in git log, does not work in less
Terminal.app:
Mouse reporting does not work out of the box, but once installed mouse wheel reporting works everywhere including less and manpages and git log, etc. However mouse click+drag fails in Tmux, but still works in Vim.
So I'd rather use just one of these terminal apps, and I am particularly digging the immense feature set of iTerm2 (e.g. mouse-over to select which term to input to beats the hell out of anything Tmux can offer since it is zero keys to switch contexts) so I'd prefer if I can get mouse wheel reporting working fully in those programs.
I am having a hard time trying to debug the terminal codes being sent because the only way I can intercept them is through Vim, (as ctrl+V followed by scroll in my terminal will just have it scroll the terminal buffer) but Vim seems to be doing everything correctly.
Update: According to mouseterm project, it seems to be using a feature called "Simulated mouse wheel scrolling" to scroll programs like less... maybe I can configure iTerm to do the same. Somehow. I do believe PuTTY also accomplishes this, and I'd like to have at least the functionality I can get on Windows on the Mac... Nope, I'm just spoiled by the neatness of MouseTerm.
Although less (which is also used in git log) does not use mouse reporting itself,
iTerm2 can be configured to send up/down-arrow escape codes for scrolling
(from mouse wheel or trackpad two-finger swipe)
and less understands those.
See my answer
to a related question about how to set this up for iTerm2.
less does not actually recognize any terminal mouse events. (As such, tools that use it, like man and git log will not recognize mouse events either.) Something else you've done must be making it appear to support mouse events.
If you want the mouse wheel to work in your pager, you'll need to find a pager other than less which supports it. You might be able to put something together using view (vim in read-only mode), but applications like man which output content with control codes will be an issue there.
Related
I want to use mouse-wheel in emacs and also scroll-back in the terminal history. When I do mosh --no-init I can scroll-back in the terminal history but I cannot use mouse wheel in the emacs. Instead if I do only mosh without --no-init flag I can use mouse-scroll in Emacs but cannot scroll back in the terminal history. I get lost in finding solution to fix this.
In mosh is it possible to scroll-back in the terminal history along with using mouse wheel in emacs, nano, less?
mosh prevents the use of scrollback #122
The root cause of not able to scroll is caused by mosh entering a
"alternative screen" mode. It can be disabled using the --no-init flag
(see the doc). Just alias mosh='mosh --no-init' and the problem
will go away.
Developers argue that:
I don't consider using --no-init as a way to get reliable access to a local scroll-back buffer. But please interpret this open issue as simply an acknowledgement of the request. We do not have any intention on implementing this feature
And recommended me from a issue I opened to use screen or tmux as a solution. But I was not able to make them work. Where when I use tmux inside the remote machine I experience that:
Scroll-back in the terminal history works, but it prevents me to copy some text from previois terminal history, it jumps back to current cursor spot right away.
Scroll-back does not work within emacs, less, nano etc.
My comment in their repsonde to mosh prevents the use of scrollback #122 labelled as This comment was marked as off-topic., which was what I mentioned in this question.
Their issue related to mosh prevents the use of scrollback #122 was open since 2012, which is around 8 years and I believe it is abandoned. If it is implemented it was implemented by now.
Contributors of mosh ignoring this issue. and saying There is hundreds of subscribers. Please think very carefully before commenting . // There was not hundreds of subscribers in the thread.
In summary, I am not having issue with --no-init, I am having issue with mosh related to mosh prevents the use of scrollback #122 , which does not support scroll back in terminal history along within tools like emacs, nano, vim, vi, less, more and so on. If a developer switching from ssh to mosh there is no way he/she can adapt the scroll behavior of mosh. Without having both together like ssh does, there is no meaning to use mosh at all.
I want to change some tmux styling when the terminal loses focus/becomes inactive (i.e. when I've clicked on an open Google Chrome window). I know I could check with the window manager to see which application window is focused, but this doesn't work across window managers.
Do terminal emulators themselves expose this information at all?
I tried running showkey -a to see if any escape sequence was sent when focus was lost, and it doesn't look like it.
I think some terminals implement this, but not all, based on this comment on the issue tracker for the vim-tmux-focus-events plugin:
About the question "I was expecting the event to fire when changing focus between different windows in my window manager": yea, I see how that would be very useful. I think this might be dependent on the terminal application you're using. I just tested this on OSX and here's some quick results:
it's working for iTerm when tmux is running inside the window
not working for iTerm running plain bash + vim inside (no tmux)
not working for Terminal.app (with or without tmux)
[...]
So, if I'm not wrong, it's up to terminal applications to implement "focus gained", "focus lost" functionality.
I have a vague memory (though I don't remember for sure) that focus gain/loss might have worked for me when using that plugin and gnome-terminal, so it might be worth a try.
I'm using bash on ubuntu on windows 10 and would like to enable scrolling using the mouse wheel in vi or vim. I've tried entering the following command in vim and added it to the .vimrc file and /usr/share/vim/vim74/debian.vim
set mouse=a
However I still can't scroll with the mouse.
I added this to my /etc/vim/vimrc.local, and it worked:
set mouse=a
map <ScrollWheelUp> <C-Y>
map <ScrollWheelDown> <C-E>
Quick and simple answer:
If you use mintty/wsltty it works just fine!
You have done, properly, all you can in vim and the problem is with your terminal emulator.
Mouse wheel scrolling through the scrollback buffer of a terminal emulator is a function of the terminal emulator which is consuming the mouse events. You are wanting to send these events to the application (vim) hooked to the terminal.
Most terminal emulators have a way to enable the passthrough of mouse events when in "Application Key Mode" or "Alternate Screen". Most also support using a modifier key (like holding ALT) that will passthrough the mouse events as you wish.
Your version of Vim may not have been compiled with mouse support. See if you can get gvim. It contains a graphical version of Vim. Depending on your distribution it may also contain the terminal vim with almost all features enabled, including mouse support.
To check for mouse support in Vim, enter :version and check whether +mouse is in the list of features.
I've been googling around trying to figure out if it's possible to use my mouse wheel to scroll while inside Vim in Mac's Terminal, with no luck. It seems as if only X11 or iTerm support this.
Before I give up, I thought I'd try the geniuses here to see if anyone knows a way to do this. So, does anyone know if I can set that up?
Or should I seriously consider using a different terminal application?
And if you're using iTerm, add this to your vimrc
:set mouse=a
http://bitheap.org/mouseterm/
Use MouseTerm (and do make sure to install SIMBL first!) and scrolling will work like a charm, even remote, using Mac Terminal.
You need to fully quit the Terminal application (Command+Q) and then launch it again after installing MouseTerm.
This is an old question, but a top hit on google, so I feel compelled to provide an updated answer.
Running OSX El Capitan 10.11, vim mouse and trackpad scrolling just worked(TM) for me in Terminal.app by default. However occasionally the mouse/trackpad input stopped manipulating the vim buffer, and started scrolling the terminal buffer. The answer was Command+R or Menu View --> Allow Mouse Reporting. Turning that on allowed the mouse/trackpad scroll operations to move the cursor in vim.
Termanal Menu > View > Allow Mouse Reporting
Terminal Menu > Preferences >
Keyboard > Scroll alternate screen
If the mouse functionalities still do not work properly take a look at my answer in this post How to let vim behave on Mac OS X as on Ubuntu?, just add to your .vimrc
set ttymouse=xterm2
You can read this article, but I'm pretty sure since the default terminal in Mac OS X has a built-in scrollbar, the mousewheel commands automatically go to it. You could definitely use gVim as suggested in the previous answer. I find that I don't generally want to use the mouse in Vim though as it takes my hands off the keyboard.
I just use 50j to go down and 50k to go up. Not exactly scrolling, but it works pretty well.
Make sure the terminal is xterm & not ansi in Terminal Menu > Preferences > Profiles > Advanced. I accidentally broke scrolling by changing the term type in a naive effort to get coloring to work over ssh.
Use gVim, which gives you a text editing environment in a window you can scroll. Terminal is not involved when using gVim.
I'm using xterm in X11 (XQuartz 2.3.4) and vim works very fine with mouse and also suport 256 colors.
Here is the ~/.Xresources I use to make my xterm nicer in X11:
XTerm*faceName: Lucida Sans Typewriter Regular
XTerm*faceSize: 9
XTerm*utf8: 1
xterm*saveLines: 1000
xterm*jumpScroll: true
!xterm*awaitInput: true
!xterm*multiScroll: true
XTerm*scrollBar: false
xterm*scrollbar*thickness: 16
xterm*rightScrollBar: true
XTerm*foreground: white
XTerm*background: grey10
!XTerm*background: black
XTerm*cursorColor: yellow
xterm*visualBell: false
xterm*loginShell: true
Little tips, to remove the bell sound in X11's xterm type this command:
xset b 0
I would recommend using iTerm - it has so many advantages over Terminal eg Mouse support, 256 colors, sensible copy and paste (auto-copy, word/url selection with double click, middle click paste)...
When using iTerm create a .vimrc file (if not already there) in your home folder and add the line:
:set mouse=a
Scrolling down in vim to view a file works after this.
I read the following code in Unix Power Tools on page 117
*VT100.Translations: #override\
Button1 <Btn3Down>: select-end(primary,CUT_BUFFER0,CLIPBOARD)\n\
!Shift <Btn2Up>: insert-selection(CLIPBOARD)\n\
~Shift ~Ctrl ~Meta <Btn2Up>: insert-selection(primary,CUT_BUFFER0)
I have not managed to see any effect of the above code.
How can you use X clipboard in Screen, without your mouse?
Using the mouse. Left-click drag to select and usually the middle mouse button pastes but some terminals may differ (PuTTY uses right-click). If you only have two buttons you click them both together (left mouse button + right mouse button).
In reply to comment below ("Can you do it without your mouse?"):
ctrl-insert : copy
shift-insert : paste
shift-delete : cut
shift-ctrl-C : copy
shift-ctrl-V : paste
Not all applications will support the last three (though Konsole does). In fact most console applications will not allow you to delete text once it's printed.
As far as selecting text without a mouse I'm not sure there's a generic mechanism for that. It's probably terminal and/or application specific (ie, vim has it's own keys for marking and copying text - but only within vim). You could do it with mouse emulation but I'm sure that would be a painful process.
You can't use the traditional Mac/Windows shortcuts in a terminal because they were reserved for different actions long before these OS existed (ie, Ctrl-C terminates the running process).
I'm trying to use Ctrl-C in X
X does not handle these operations directly, they are handled by the application. That's why modern GUI programs like Firefox or Gedit support Ctrl-C for copy but terminals and command-line programs generally do not. As I said, it's a conflict in established conventions and Ctrl-C for kill got in first.
BTW, you could do some key-remapping if it drives you nuts but then you would be learning bad habits when you use a different machine. Best to just get used to it or do most of your editing in a GUI application.
More Information
EDIT: For a Mac, this may help: MacOSX-to-Konsole or This or This. It looks like you need to replace Ctrl with Command on Mac keyboards. It seems like Terminal the mac console has a right-click context menu for copy-paste so to do it the traditional way you me need to install a different console program or change some settings in Terminal.