Ubuntu 20.04.3, tmux 3.0a, micro text editor v2.0.10
Description of issue
When using the micro text editor within a tmux window, typing modifier key + arrows just echo the text of the key code instead of performing the the navigation or selection actions.
Debug info
my ~/.tmux.conf doesn't have any key bindings associated to Shift-arrows, Ctrl-arrows, Alt-arrows, Ctrl-Shift-arrows.
Here is literally the content of the micro editor when typing xxx-arrows
Shift Left/Right: [1;2D] [1;2C]
Shift Up/Down : [1;2A] [1;2B]
Ctrl Left/Right: [1;5D] [1;5C]
Ctrl Up/Down : [1;5A] [1;5B]
C-Sht Left/Right: [1;6D] [1;6C]
C-Sht Up/Down : [1;6A] [1;6B]
Alt Left/Right : [1;3D] [1;3C]
Alt Up/Down : [1;3A] [1;3D]
Running micro outside of tmux, for example in Gnome terminal. There is no problem. ie the modifier key + arrows performs their intended actions.
Running nano or vim within tmux, the modifier key + arrows does NOT echo the keycode [1;xx] in the editor area.
Also tried to enable the following option in ~/.tmux.conf (and reload the config)
set-window-option -g xterm-keys on
set-option -g xterm-keys on
There is no improvement whether one or both of the options is enable. Currently my ~/.tmux.conf doesn't set any of those options.
QUESTION
Is this issue related to tmux or the micro text editor? And hopefully there is a fix.
Workaround (by micro author): https://github.com/zyedidia/micro/issues/983#issuecomment-355867571
Edit ~/.config/micro/bindings.json, add
{
"\u001b[1;2A": "SelectUp",
"\u001b[1;2B": "SelectDown",
"\u001b[1;2C": "SelectRight",
"\u001b[1;2D": "SelectLeft",
"\u001b[1;3D": "WordLeft",
"\u001b[1;3C": "WordRight",
"\u001b[1;3A": "MoveLinesUp",
"\u001b[1;3B": "MoveLinesDown",
"\u001b[1;4C": "SelectWordRight",
"\u001b[1;4D": "SelectWordLeft",
"\u001b[1;5D": "StartOfLine",
"\u001b[1;5C": "EndOfLine",
"\u001b[1;6D": "SelectToStartOfLine",
"\u001b[1;6C": "SelectToEndOfLine",
"\u001b[1;5A": "CursorStart",
"\u001b[1;5B": "CursorEnd",
"\u001b[1;6A": "SelectToStart",
"\u001b[1;6B": "SelectToEnd"
}
Related
BACKGROUND
When running sbt, I must press a "dead" key after each press of <ENTER>; meaning that pressing <ENTER> appears to do nothing... until I press another key -- any key -- when sbt ignores the follow-up key (i.e., "dead key") but behaves as if <ENTER> had been pressed.
After looking into the issue, I discovered that a system property ("jline.terminal") affects this behavior. This property can be one of {"auto", "unix", "win", "windows", "none", "off", "false", xxx} where xxx refers to a class implementing jline.Terminal.
When I set jline.terminal to be one of {"off", "false", "none"}, the problem with "broken <ENTER>" goes away. However, this mode drops support for the linux Readline library (i.e., up-arrow yields "^[[A" instead of recalling a line from the input history buffer).
So, I have 2 options:
Use "unix" as my jline.terminal and press <ENTER> + at the end of each input line; or
Use "none"|"off"|"false" as my jline.terminal and lose my command history support
How can I have both: a working <ENTER> key AND support for the Readline library?
ENVIRONMENT
OS: Ubuntu 17.10
Java: 1.8.0_161
sbt: 1.1.2
I have installed vim-mode-plus package and added the following keymap bindings in the keymap.cson file.
'atom-text-editor.vim-mode-plus.normal-mode':
'ctrl-j': 'focus-pane-or-panel:focus-below'
'ctrl-k': 'focus-pane-or-panel:focus-above'
'ctrl-h': 'focus-pane-or-panel:focus-on-left'
however I am not able to switch between the panes ( I am on Windows)
I am able to switch if I use a built-in keybinding as below:
ctrl-w ctrl-j window:focus-pane-below Vim Mode Plus atom-text-editor.vim-mode-plus:not(.insert-mode)
Above is copied from the Keybindings search results in atom
I don't think you are using the right command names. If you open the Command Palette (CtrlShiftP), you can search "focus" and find the various commands available for what you're trying to do.
Window: Focus Pane Above
Window: Focus Pane Below
Window: Focus Pane On Left
Window: Focus Pane On Right
To turn these into keybind command names, apply this formula:
Lowercase everything
Remove the space after :
Replace remaining spaces with hyphens
This gives the keybind command names:
window:focus-pane-above
window:focus-pane-below
window:focus-pane-on-left
window:focus-pane-on-right
Also notice the working example you point to uses a different selector than you are using. It uses atom-text-editor.vim-mode-plus:not(.insert-mode) rather than atom-text-editor.vim-mode-plus.normal-mode. That may be a better option, so your key bindings would work in modes other than normal mode (such as visual select mode).
I think what you need is:
'atom-text-editor.vim-mode-plus:not(.insert-mode)':
'ctrl-j': 'window:focus-pane-below'
'ctrl-k': 'window:focus-pane-above'
'ctrl-h': 'window:focus-pane-on-left'
And I'm not sure if you also wanted CtrlL to work, e.g.
'ctrl-l': 'window:focus-pane-on-right'
I've removed and added a few times now the following line to ~/.tmux.conf:
set -ga terminal-overrides ',xterm*:smcup#:rmcup#'
Which according to the person who provided it does the following:
to fool the multiplexers into thinking that the terminal has no "alternate screen" mode (such as that used by pico, mutt, etc). This is accomplished by setting termcap commands for the session.
The 'xterm*' part of the command should be set to whatever your terminal-emulator is declared as.
The end result is that the overflow ends up in the terminal's scrollback buffer instead of disappearing. Of course, since this is one static buffer, things will get messy as you switch between screen or tmux windows, but this is handy for quickly flicking up to see the output of an ls command or the such.
I don't quite understand the bolded section (emphasis added), but guess this is the source of what I'm seeing. It's causing some weird sort of unicode overspill upon exiting tmux.
Pasted as plaintext this text won't show up, but the symbol [001B]112 appears alongside the usual [exited]:
]112[exited]
(FWIW I think it has pasted in that line, but isn't displaying)
I followed this advice ("Use terminal scrollbar with tmux"), and while it does work, this is just ugly/annoying to see that upon exiting. Can anyone advise how to fix or avoid the output message?
Offhand, I would get the unwanted "message" is some hard-coded application (or script) which is helpfully resetting the xterm dynamic text cursor color. See XTerm Control Sequences in the description of Operating System Controls:
The dynamic colors can also be reset to their default
(resource) values:
...
Ps = 1 1 2 -> Reset text cursor color.
So... somewhere there is some script doing the equivalent of
echo -n -e '\e]112\a
The results probably depend most on what particular terminal emulator you are using. Both screen and tmux filter out escape sequences that their developers did not care to implement, and pass through those that the terminal "should" handle.
Just take a look at sentence you provided: "The 'xterm*' part of the command should be set to whatever your terminal-emulator is declared as."
In my case, the $TERM has value xterm-256color and the corresponding line in ~/.tmux.conf looks like:
set -g terminal-overrides "xterm-color256:smcup#:rmcup#"
To clarify, I mean the icon that is displayed when the app is running (e.g. inside the dock).
With trial and error, I found out that it uses "/usr/share/pixmap/xfce4-terminal.xpm" as the icon (tested by replacing this file with some other icon).
I was unable to find where it maps the running xterm to this icon.
If I copy the xterm binary to a different name and run that one, it gets a different icon, which shows that there is a possibility to change it.
I already tried setting the "xterm*iconPixmap:" resource, but that appears to have no effect at all.
You could try using xseticon
usage: xseticon [options] path/to/icon.png
options:
-name : apply icon to the window of the name supplied
-id : apply icon to the window id supplied
Sets the window icon to the specified .png image. The image is loaded from
the file at runtime and sent to the X server; thereafter the file does not
need to exist, and can be deleted/renamed/modified without the X server or
window manager noticing.
If no window selection option is specified, the window can be interactively
selected using the cursor.
Hints: xseticon -id "$WINDOWID" path/to/icon.png Will set the icon for an xterm.
********** EDIT **********
I think you need the imagemagick program installed to access the convert command. Then, find an icon that you like and convert it to an xbm file:
Code:
convert /path/to/icon/file /path/to/xterm.xbm
Create an ~/.Xresources file with the following content:
Code:
xterm*iconPixmap: /path/to/xterm.xbm
Then merge in the ~/Xresources file:
Code:
xrdb -merge ~/.Xresources
The update came from: http://forum.xfce.org/viewtopic.php?id=6779
I finally managed to do by setting *iconHint on the xterm resource.
The value needs to be a path to an .xpm file WITHOUT the extension.
X resources that you want to be loaded at login time need to go into an ~/.Xdefaults file.
So a complete solution for an icon my-xterm.xpm would be:
mkdir ~/.icons
mv my-xterm.xpm ~/.icons/
echo 'xterm*iconHint: '$HOME'/.icons/my-xterm' >> ~/.Xdefaults
If you want your changed ~/.Xdefaults to become active without logging in, run xrdb -merge ~/.Xdefaults
If you just want one xterm to have a different icon, you can start the xterm like this:
xterm -xrm 'xterm*iconHint: /full/path/to/icon' …
Not 100% sure that changing the .desktop file would help in XFCE. But it's a worth a shot.
Find the path to your local icons, here is in the sub path of
/usr/local/share/icons.
Then simply copy the .desktop file to you home dir eg:
cp /usr/share/applications/xterm-color.desktop ~/.local/share/applications/
Then edit the .dekstop fil in an editor, there is a line like this:
Icon=xterm-color
Replace this with a icon name from your icons path and logout and back in and you should be good to go. (The icon should not have the file extention like .png or .svg).
Here's what happens. I'm using Vim + LaTeX-Suite to edit TeX files in Vim. This could be in the Terminal or in MacVim.
I happily
Insert lots of $\LaTeX \commands$ etc. I love using the $\backslash$.
TeX works great. No problem.
Then I go and open up a .R file in the same window (different tab). R-Plugin for Vim uses the <Leader> key (mapped to \ as per usual) to execute commands, e.g. I type \sa to send the selection to R and execute and move the window down. Life is nice.
Problem: even though while editing an R file, Vim is nice enough not to bug me in insert mode when I type \, for some reason when I switch back to the tab to edit the TeX file, then type \ in insert mode, it moves the cursor left of the \ and pauses as though waiting for the rest of the command, before then re-moving to the right of the \ and moving on as I type.
Below shows what happens just from typing \ in insert mode; obviously I could reproduce this by moving the cursor to the left with the arrow keys, but that's not how this happened--the cursor just moves left for a split second as though waiting for the R command to finish being input.
So: how can I stop the annoying behavior in the TeX file insert mode, without sacrificing other functionality? Note, (a) I don't expect mapping <Leader> to a different key to help since then that key will just have the same left-cursor-move problem in TeX; (b), I like the leader as \ anyway so I don't want to change it.
Put this line in your vimrc (requires Vim-R-plugin >= 0.9.9.2):
let g:vimrplugin_insert_mode_cmds = 0
If the problem persists, you can do the following in Normal mode to know what are the keyboard shortcuts in Insert mode:
:imap