Micro: shift is not recognized in screen/tmux session

Created on 6 Jan 2018  路  14Comments  路  Source: zyedidia/micro

Description of the problem or steps to reproduce

  • start tmux or screen (terminal multiplexers)
  • try to select text using shift+arrow
  • cursor does not move as long as I hold shift

Workaround:

1) add options to tmux.conf
set -g default-terminal xterm
set-window-option -g xterm-keys on

with those settings, text selection in micro works, but they don't work so great for other applications - htop's display doesn't get updated properly, whether I use urxvt or xterm.

1.5) use a gnome-terminal-based terminal emulator (i tried mate-terminal)

With this, htop still looks a little funky, but at least there are no artifacts when using the search function.

Specifications

Commit hash: 5fc8f84
OS: Ubuntu 16.04
Terminal: urxvt, xterm, mate-terminal

Most helpful comment

Alright so I think I misunderstood the issue earlier. It turns out the terminfo entry for screen just doesn't have any information for what escape sequences it will send for Shift-Arrows, so micro has no idea what to look for. But it turns out that screen does send the same escape sequences as xterm it just doesn't tell micro what it's going to do.

You can fix this with some raw bindings though by putting the following in your bindings.json:

{
    "\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"
}

This will fix the bindings for Ctrl, Shift, Alt, CtrlShift, and AltShift.

Sorry but there doesn't seem to be a better fix to this.

All 14 comments

Same problem here.

probably related but closed for some reason

yeah that is probably the simplest way to go, however if it does not work in tmux it's not so usable for alacritty users as alacritty kind of needs tmux

1
2

micro gets the shift+up sequence but does nothing when running in tmux (this was the case with or without set-window-option -g xterm-keys on)

Yes that's pretty weird. Micro seems to be receiving the correct escape sequences when looking in raw mode. This probably has to do with tcell initialization going wrong at some point.

Ok here's a simple fix for the shift problem. You can run the mkinfo program and that fixes it. The special arrow keys still don't work though. I'll keep investigating.

Another possible fix is to run export TERM=xterm-256color. This seems to fix everything. Clearly tcell is somehow getting confused by the screen terminal.

Another possible fix is to run export TERM=xterm-256color. This seems to fix everything. Clearly tcell is somehow getting confused by the screen terminal.

just tried (putting into .bash_profile) and indeed seems to be the case as far as I can tell, thanks!

not sure why though cause my alacritty.yml also has TERM: xterm-256color so seems redundant

Another possible fix is to run export TERM=xterm-256color. This seems to fix everything.

The issue with htop remains. To show what I mean, I made some screenshots:

Expected: (urxvt + htop)
2018-01-06-230647_735x488_scrot

Actual: (urxvt + tmux + htop)
2018-01-06-230548_661x488_scrot

Note the additional processes displayed under the gap, and the way the color rows don't fill the entire width. This behavior is consisted for TERM=xterm.

Using mkinfo should fix the issue with shift characters and I would expect it to not change the behavior of htop.

I'm still interested in looking into why the arrow keys don't work with special modifiers in tmux. I think it has to do with the terminfo database for screen not containing those key codes even though they are being sent.

honestly this mkinfo feels more like a hack to me... shoudn't this be included into micro to make it more resilient? at least at some point in the future ...

Alright so I think I misunderstood the issue earlier. It turns out the terminfo entry for screen just doesn't have any information for what escape sequences it will send for Shift-Arrows, so micro has no idea what to look for. But it turns out that screen does send the same escape sequences as xterm it just doesn't tell micro what it's going to do.

You can fix this with some raw bindings though by putting the following in your bindings.json:

{
    "\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"
}

This will fix the bindings for Ctrl, Shift, Alt, CtrlShift, and AltShift.

Sorry but there doesn't seem to be a better fix to this.

A few additional considerations:

  • The suggestion to have export TERM=xterm-256color inside a tmux session is not recommended
  • It doesn't matter what the value of TERM is outside tmux, it is likely changed to something like screen-256color (if you want full color support)
  • Take into account your terminal might not implement escape sequences in a manner that works with tmux, micro, or both (two examples: alacritty and #1335)

Solutions:

  • The one posted by @zyedidia right above works great
  • Two steps that _might_ work

    • Run (or alias) tmux to tmux -2 so it assumes your terminal supports 256 colors (it should, but you should make sure it does)

    • Start micro like so: TERM=xterm-256color micro

Seems like the workaround indeed is aliasing micro to TERM=xterm-256color micro or bindings.json ;_;

@ecx86 See https://github.com/zyedidia/micro/issues/1489#issuecomment-587116459. There's also the recently added xterm option as a workaround.

@joshuarli Thanks!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

GeigerCounter picture GeigerCounter  路  3Comments

nabeelomer picture nabeelomer  路  4Comments

luis-lavaire picture luis-lavaire  路  3Comments

johnmbaughman picture johnmbaughman  路  3Comments

Bigguy34 picture Bigguy34  路  3Comments