• 4
name Punditsdkoslkdosdkoskdo

How to convert Home / End behaviour on Yosemite

I want to change the Home and End keys to work like Windows/Linux.


Home to Command-Left Arrow. // Beginning of the line

End to Cmd-Right Arrow. // End of the line

I tried using Karabiner app known as KeyRemap4MacBook. But it doesn't work on Yosemite while I write code on editors like Sublime Text, PhpStorm, WebStorm, etc.

I also did create a DefaultKeyBindings.dict file (with proper settings) inside ~/Library/KeyBindings/ and OSX/Library/KeyBindings/.

So, is there a way to remap the Home and End keys for glabally on my mac. I could use Terminal command too. I don't want an app for that.

What is the code for the JSON file to re-map the following:

1. Change Home key to send Ctrl+A to Mac
2. Change End key to send Ctrl+E to Mac
3. Change Cmd+Y to send Cmd+Shift+Z to Mac

These are the only mappings I use in the full version of Karabiner, and I want to enable them after upgrade to Sierra on the Elements.

  • 1
Reply Report

xterm-style terminals send two different sequences for each of UpDownRightLeftHome, and End. In “normal cursor keys” mode, the sequences start with ^[[ (ESC [); in “application cursor keys” mode, the sequences start with ^[O (ESC O). The sequence for End ends with F, so it is ^[[F under “normal cursor keys” mode and ^[OF under “application cursor keys” mode.

tmux 1.8 recognizes both of these sequences by default, so you should not need to do anything special have tmux 1.8 reliably recognize xterm-style Home and End sequences (i.e. no need for the terminal-overrides hack described below).

The rest of this post describes a way to get these keys working work tmux versions prior to 1.8.

Versions of tmux prior to 1.8 only recognize End when sees the sequence provided in the kendcapability of your attached terminal’s terminfo entry (as specified by TERM when you attach to a tmux session). By default, tmux switches the client terminal to “normal cursor keys” mode1. This ends up meaning that tmux will not recognize End because the terminal sends the “normal cursor keys” sequence but tmux only knows about the “application cursor keys” sequence (from kend).

Basically, tmux seems to expect that Home and End are not affected by the cursor key mode. This incompatibility with xterm-style terminals results in the key not being recognized properly2.

There is a kind of loop-hole here that you can use to verify that this is happening: run tput smkx (or start Emacs or Vim) in your active pane. As long as that pane is active, tmux should recognize Home and End. This happens because smkx sends a sequence to tmux that causes it to send smkx to the client (which switches the client into “application cursor keys” mode, which sends sequences for Home and End that tmux will be able to match against the sequences from khomeand kend). This is not a very good workaround, however, because the “application” vs. “normal” state will also be set and reset by interactive or full-screen programs (e.g. Emacs and Vim) when they start/resume and exit/suspend.

A better workaround would be to use tmux’s terminal-overrides option to change kend (and khome) to the “normal” sequences and remove “application cursor keys” changes from smkx and rmkx (to prevent switching to “application cursor keys” mode, where Home and End would send the (now unrecognized) sequences). The arrow keys have special support, so they will always be recognized (assuming xterm-style sequences). If you are using TERM=xterm=256color to connect to tmux, you could do this in your (~/.tmux.conf):

set-option -ga terminal-overrides ',xterm-256color:kend=E[F:khome=E[H:smkx=E=:rmkx=E>'

(Note: because of the way terminfo entries are processed by tmux you will need to disconnect all your existing xterm-256color clients before the overrides will take effect. Also the values for smkxand rmkx used above assume that the keypad mode sequence is all that remains once the cursor keys mode sequence has been removed from each.)

Ultimately, this is probably a bug in tmux. It should probably either

  • include Home and End in the special support that the arrow keys get for recognizing both normal mode and application mode sequences, or
  • always put the client terminal in “keyboard transmit” mode, and send the appropriate sequence for TERM=screen depending on whether the pane has requested normal or application cursor or keypad mode3.

1 Actually, it sends the terminfo capability rmkx (”end keyboard transmit mode”), which—for xterm-like terminfo entries—switches to “normal cursor keys” mode and “normal kaypad” mode.
2 Because the ^[[F sequence is not recognized as a single key, it ends up being processed as two “key combinations”: ^[[ (ESC [, which is treated as M-[), and a plain F.
3 The revision control history indicates that this method (always in keyboard transmit mode, emulate cursor/keypad modes for each pane) was used at one point in the past. I am not clear why it was changed to the current behavior (track keypad mode of the active pane); there may have been some problem with this approach.

  • 1
Reply Report