How can I get shift+arrow keys working in tmux - tmux

I tried adding the below to ~/.tmux.conf so that i could use Shift+arrow keys to jump across windows, but doesnt work.
bind -n S-Left previous-window
bind -n S-Right next-window
This is not under vim as I saw in other qns answered in stackoverflow. Even if I tried to use this for navigating across panes it doesnt work. However, if I use the Alt+arrow keys it works like a charm.
Any way I could get the Shift+arrow mappings work?

Although PuTTY sets the TERM variable to xterm, its behavior does not in fact match xterm's behavior link
There is a bug in PuTTy which causes binding of shift key to not work link
Your can switch to KiTTy, a fork of PuTTY, which solves the problem you are facing,

Related

How to make Tmux share only Vim commands and not text?

I'm trying to find a way of live-code music together with others, real time and collaboratively, like one would do in a document editor as Etherpad or Google Docs.
I have tried some specific tools for that (e.g: Troop and Flok), but I would like to stay in Neovim.
Then I tried Tmux, which is great because when a client evaluates a block of code that will be done for all clients in that session, but just one person can write at a time and that won't work for live coding together.
This really nice plugin for Neovim: Instant allows multiple clients coding together in Neovim each one with its own cursor, but it only shares text.
Is there a way for Tmux to share only the vim commands, native or from plugins, and not text? So, one could use both Tmux and Instant and have the best of both worlds.
I'm using Ubuntu Studio 22.04, NeoVim v0.8.0-dev-1081-g907fc8ac3, tmux (I couldn't find which version), scnvim and tidal-vim for livecoding.
Thank you all in advance for any directions.

R : Using shortcuts to insert operators writes to a different file

I'm sharing a small but annoying issue that sometimes pops up when I'm using shortcuts to insert operators while working on a markdown file in R : the operator either does not get written, or even worse gets written on another file.
So let's say I am working on the file "report.rmd", and I want to insert the pipe operator using Ctrl+Maj+M, or the assignment operator using "Alt+-", and I have the file "test.R" opened. Well, I therefore type the aforementioned shortcuts and...nothing happens on my markdown file. But some nice operators that had nothing to do there get written on my test.R file.
The only way I found to solve this problem is to close and reopen RStudio (restarting unfortunately doesn't solve the issue).
While this is quite a minor problem, it's incredibly annoying. Did it ever happen to anyone of you, and if so do you know where it comes from and how to solve it?
Edit:
Although I am still running into this issue (without being able to reproduce it consistently) I came into a somewhat lighter solution. Instead of restarting R, simply closing all tabs (closing just the problematic one doesn't work) solves the problem. I hope this helps narrowing down the possible origins of the problem.
Short Answer
re-define the key combo to Ctrl+Shift+ \ , assuming this does not create a conflict
Background
I've had a similar problem for a while, too. In my case, the shortcut never works. I can not find the source. I even found a conflict with Ctrl+Shift+M assigned to 2 Editor functions.
Image:Screen Capture 2 conflicting hotkey assignments
However, a simple key reassignment of the one that is not the pipe operator ("Expand to Matching")
Image:screen capture showing the hotkey conflict solveddidn't solve the issue in my case.
Solution
Here's what did the job for me
I managed to assign a different combo (that hasn't been assigned yet) and that is comfortable enough in the sense of its location on the keyboard
go to Tools → Modify Keyboard Shortcuts...
In the filter box, write "Pipe"
Direct the cursor to the text box showing the current shortcut, and press the new combo (e.g. Ctrl+Shift+ \ ), then Enter.
Remember to hit Apply
Make sure the new Combo isn't a duplicate of another command, by going back to step 1 and sorting the list by Shortcut, then scrolling down to find your new one. if there is an ovelap, consider changing one of them.

Atom keymap combos dont work with arrow keys

I have this in my keymap.cson file:
'body':
'ctrl-alt-left': 'editor:select-to-first-character-of-line'
But it doesn't work (there is no effect).
The following keymaps do work:
'body':
'ctrl-alt-a': 'editor:move-to-beginning-of-line'
'ctrl-alt-e': 'editor:move-to-end-of-line'
'ctrl-alt-shift-s': 'editor:select-to-first-character-of-line'
'ctrl-alt-shift-w': 'editor:select-to-end-of-line'
But I would like to be able to use the arrow keys.
I'm not sure where you got the body selector from. You should use atom-text-editor for maps like this, as in the examples in the default keymap.cson in your .atom folder. This should do what you want:
'atom-text-editor':
'ctrl-alt-left': 'editor:move-to-beginning-of-line'
'ctrl-alt-right': 'editor:move-to-end-of-line'
'ctrl-alt-shift-left': 'editor:select-to-first-character-of-line'
'ctrl-alt-shift-right': 'editor:select-to-end-of-line'
When debugging issues like this, you must also keep a couple of other things in mind.
First, the meaning of alt varies by platform. On macOS, it means the Option key. On Windows or Linux, I believe it means the key labeled Alt, but your keyboard may be a bit different (especially non-US layouts).
Second, if a higher layer of the system (the OS itself, i.e. the window manager) is capturing a key combination, then it will never reach Atom at all. You can detect this situation using the Key Binding Resolver. You can activate it using Cmd. on macOS. I am not sure about other platforms, but usually Cmd on macOS maps to Ctrl on Windows and Linux, so I would suggest Ctrl..
While the Key Binding resolver is active, any keys or key combinations you press are listed in the resolver, along with the action (if any) within Atom that is taken. You can use this to determine what Atom thinks a given key is, and you can also use it to detect whether a given key combination is not reaching Atom in the first place.

Spacemacs escape key needs delay to work

I have clean install of spacemacs. When I press escape to enter normal mode then immediately press u it will uppercase a word. If I wait a second, it will undo last action.
I'm assuming this is evil-mode or emacs key-chord feature in action. How can I change that behavior?
Spacemacs, particularly the develop branch should just work right out of box without the delay. However, I have found that this delay happens when I am running emacs inside of tmux. You should see if you are trying to run this inside tmux or screen, and if you are, see if this problem happens when you run emacs directly inside a terminal, without a terminal multiplexer.
If tmux is your problem, you can fix this with:
set -s escape-time 0
You'll have to find the equivalent in screen if that is what is happening.
See: https://bitbucket.org/lyro/evil/issue/69/delay-between-esc-or-c-and-modeswitch
Zeroing out my delay as Ho-Sheng Hsiao suggested has served me well, but as Wesley Baugh pointed out, that has the consequence of preventing the use of ALT-key modifiers in your editors.
The Emacs-evil FAQ addresses the problem, but not very succinctly, and without a concrete recommendation.
The Neovim FAQ has a more succinct explanation, and a specific recommendation:
set-option -sg escape-time 10 # millisecond delay

How to make tmux's reaction faster?

I use tmux and find one problem of it.
For example, I make 2 panes within 1 window under tmux.
In one pane, I compile Linux kernel and as you know it will output a lot of message there.
During the compilation, in another pane of tmux, when I tried to input some command, it will react very slow.
How to solve this?
Thanks!
BR
With two panes, tmux has to update two portions of the screen at once. My suggestion is to let the compile running in a separate window, so that tmux doesn't need to render so much output to the visible screen, and configure some sort of monitor on the compile window so you will be notified when it is finished.
As chepner says, tmux has to send a lot more characters to update a bigger part of the screen. In my case, enabling ssh compression reduced this kind of slowness quite a lot. You can give it a try with:
ssh -C user#host
or put Compression yes into your ~/.ssh/config to make it permanent.
Question asked in June.. 2012?! ^^
If you are using X11, try a different terminal. Besides those based on xterm there are KDE's konsole and it's variants (like yakuake drop-down terminal) and GNOME's VTE and offsprings (like guake drop-down terminal :)), display update speed can be very different.
Furthermore, a rate limiting feature was implemented in march which will be in the 1.7 release out soon.

Resources