Quite often but not always I'd receive some strange keystrokes in my terminal(OS X El Capitan). It looks like a sequence of:
^[[O^[[I
^[[O^[[I^[[O^[[I^[[O^[[I^[[O^[[I^[[O^[[I^C
this is so annoying especially when I have vim open it seems to bring up identifier search and I have to hit Enter to continue each time. I can verify this happens in iterm2 as well.
Did this ever happen to anyone else?
Those are an artifact of the changes in El Capitan to support xterm-style mouse protocol. The odd characters can tell a program when the mouse has moved in/out of the window (or clicked to gain/lose focus).
Some application you have run turns on this feature without handling it properly (or stopping it when the application ends).
Further reading:
FocusIn/FocusOut (XTerm Control Sequences)
Mouse Tracking (XTerm Control Sequences)
Related
I have a MacBook Pro running Catalina with an additional display. I typically have my development-related apps on one display (iTerm2, VSCode, etc.) and everything else on the other display (Chrome, Slack, etc.)
Sometimes (not all the time), when I switch desktops (Ctrl+left or Ctrl+right), access an app using Spotlight (Cmd+space and type), or use Cmd+Tab to switch applications, the focus would suddenly jump to iTerm2 or VSCode. This happens even if iTerm2 or VSCode isn't currently showing; for example, if I try to switch to Chrome on display 1 and iTerm2 is on a different hidden desktop on display 2, Chrome would appear on display 1 and then display 2 would show the desktop containing iTerm2 sliding into view (along with focusing iTerm2).
This severely impacts workflow, since this behavior is unpredictable and involves a lot of typing in the wrong application and reaching for the mouse. What is causing this behavior?
I found that it only happens when I have windows of the same app on both screens.
Say I switch desktop on a screen 1 and Chrome should become active there, then if I also have a Chrome window on my screen 2, it's actually the one on screen 2 that becomes active. Very frustrating..
This bug still exists in macOS Big Sur 11.4. Another symptom is that, after the erroneous focusing happens, manually switching to a space with no windows in it will leave that focused app focused, after briefly focusing Finder, rather than just focusing Finder. It's this last erroneous focusing that causes the space-switching.
Workaround: when it happens, invoke "Show All" from the menu bar (I have a keyboard shortcut for this). Note that switching to an empty space now does a single focusing of Finder, and no further space-switching happens.
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 have this weird problem, i often use cmd+tab to switch between opened applications. After upgrading my OS to El Capitan it started to behave weird. Sometimes it doesn't switch to last focused window but it switches to last application visible on that bar which is displayed after pressing this shortcut. It really freaks me out. Please help.
To explain this problem better i've recorded a video: https://www.youtube.com/watch?v=R6gKsCTLt00 when this bug occurs i stop for a while and point my cursor on the application item on that bar.
I have to mention than all this time i'm using cmd+tab only, without shift pressed.
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.
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.