Normally, I can find solutions by just googling around, but I can't find any decent documentation for xkbdmap except for the grossly inadequate man page.
Perhaps I'm going about this the wrong way. I have a US 105 plain old keyboard that does not have an AltGR key. To the right of the space bar, I have Alt, Windows key, some sort of menu key, and then a Control key.
(what's the point of the Windows key and the Menu key - does anyone actually use those?)
Apparently, some keyboard have another key which is the AltGR key. That with E would give you a Euro symbol for instance, apparently.
Because my keyboard doesn't have this key, I thought to use the xkbdmap command like this:
xkbdmap altgr:rwin
Why does this not work?
There's no xkbdmap command in the standard xorg distribution. You probably can use xmodmap but generally things are done slightly differently in the X11 land nowadays. If you use XKB (everybody uses XKB now) then there are virtual modifiers such as "compose" and "meta" and "level 3 chooser" which are mapped to real keys. This is done with the setxkbmap command. You probably want either
setxkbmap -option -option compose:rwin
or
setxkbmap -option -option lv3:rwin_switch,eurosign:e
depending on what exactly you want. Google setxkbmap options to figure out your possibilities.
(The first empty -option argument clears existing options, the second one adds to existing options. If you want to keep existing options, skip the first -option. Current options are stored in the properties of the root window.)
Note that most keyboards that have AltGr lack the right Alt key. If you want your right Alt to act like AltGr, change rwin to ralt in the above commands.
Related
The control and command keys are basically analogs when it comes to computer applications, when I'm talking about them in a cross-platform application, what should they be called? Is there a term like " the _______ key"?
Alt / Shift / Control / Command - they're all modifier keys. Ctrl/Command are analogs in the sense that they're used for "command"-type shortcuts, i.e. performing some action. Maybe a C-modifier key or action-modifier key would be the right names.
"Modifier key" is the term at least used many online dictionaries and documentation. (Including Apple and IBM.) (As used but not quite advocated in ALGOholic's answer.)
FYI there is an old term that has been used: "bucky (bit) keys". From The Hacker's Dictionary:
BUCKY BITS noun.
Control characters are so useful that sometimes special keyboards
are built that have even more shift keys. One of the first of these was
used at Stanford. It had the usual shift and control keys, and a third
key called "meta", as well as lots of unusual characters such as Greek
letter. So, one can type such characters as control-F, meta-N, and
control-meta-B.
Now, when you type a character on a Stanford keyboard, the
following information is sent to the computer: a code indicating the
basic character, plus one BIT for each shifting key to indicate whether
that shifting key was pressed along with the basic character key.
Programs usually treat the regular shift key as part of the basic
character, indicating whether you want lower case or upper case (or
whether you want "3" or "#", and so on). The other bits (control and
meta) are called the bucky bits.
(Observe that the source itself refers to "shift keys" and "shifting keys".
See also the jargon file glossary:
bucky bits: /buh'kee bits/, n.
[obs.] The bits produced by the CONTROL and META shift keys on a SAIL keyboard [...] (see space-cadet keyboard).
By extension, bits associated with ‘extra’ shift keys on any keyboard, e.g., the ALT on an IBM PC or command and option keys on a Macintosh.
Observe that the source itself refers to the bucky keys as "‘extra’ shift keys".
(I observe that "Bucky bits" & "space cadet keyboard" are referenced in the Wikipedia entry for "modifier key". Unfortunately, there isn't an etymology for "modifier key" itself.)
First off, I'm using Opensuse 13.2 64-bit and also Arch_Linux 64-bit
Can't get the bind to work for either of them (well, the binds that I want), but I'm mostly focused on the Arch_Linux. Also, using openbox wm, xfce4-terminal. ( in opensuse using konsole and gnome 3) and my $TERM is set to xterm-256color in my ~/.bashrc and is switched to screen-256color when using screen in opensuse, but strangely is not changed in Arch.
I want to bind C-a down: to focus down, C-a up: to focus up, C-a left: to focus left etc.. Lets just focus on focus down for the moment.
I've tried everything in my ~/.screenrc file
bind "\E[B" focus down
bind "\EOB" focus down
bind "^[[B" focus down
bind "^[OB" focus down
bind "\033[B" focus down
bind "\033OB" focus down
bind "\033\133\102" focus down
bind j focus down # works fine
Nothing catches the down arrow key. I CAN use the following
bind -k kd focus down
however, I also want to bind multiple keys using the arrows and AFAIK the -k option only allows binding 1 key (or shift + left/right) . Actually I'm lucky I can even use the -k option since it is not documented.
Now I've checked my kd (termcap) and kcud1 (terminfo) using infocmp
infocmp -1 | grep kcud1
kcud1=\EOB,
infocmp -1C | grep kd
:kd=\EOB:\
and BTW these symbols can be looked up here for termcap and here for terminfo and its termcap equivelancies (actually I guess you can just use: man terminfo)
when I use Ctrl-v and press down arrow I get
^[[B
showkey -a
^[[B 27 0033 0x1b
91 0133 0x5b
66 0102 0x42
Anyone know how to go about this. I want to know why I can't use bind without the -k termcap_name and/or how to use combo of keys(such as ctrl/alt) and termcap names. Thanks for all and any info.
I've tried setting termcapinfo also with no luck. don't think I'm using it right.
termcapinfo * kd=\EOB
bind "\EOB" focus down
termcapinfo * kd=\E[B
bind "\E[B" focus down
etc...
It appears that GNU screen doesn't permit binding sequences of multiple keys.
Quoting the man page:
bind [-c class] key [command [args]]
Bind a command to a key.
...
The key argument is either a single
character, a two-character sequence of the form "^x" (meaning
"C-x"), a backslash followed by an octal number (specifying
the ASCII code of the character), or a backslash followed by a
second character, such as "\^" or "\". The argument can also
be quoted, if you like.
...
As said in this answer, try:
bindkey "^A^[OB" focus down
The vim trick is really helpful to get the code for the combinations you want (for example, if you wanted the combo Ctrla Ctrldown instead of Ctrla down, this would be ^[[1;5B instead of ^[OB).
Credit should go to koyae for the original answer.
It seems like this article by Steve Losh has been making the rounds, and in short, it led me to remap Caps Lock to F19, and at the system level, to remap F19 to Shift-Command-Ctrl-Alt, thus giving me an entire namespace for my own keyboard shortcuts.
The problem is I enjoyed using Caps Lock as my escape key in Vim.
I tried :map <M-C-D-S> <esc>, but upon sourcing, hitting caps lock doesn't do anything. I'm guessing it's because Vim expects an actual key to be pressed with the modifiers.
My question is: is it possible to have Vim read Shift-Cmd-Ctrl-Alt as Escape?
No, you can't map four modifiers. Not even three, Not even two. And, well… not even one.
"Modifiers" are called "modifiers" for a reason: they are used with normal keys to "modify" their meaning. The Shift, Alt, Cmd and Ctrl keys don't do anything on their own and Vim rightfully does nothing but wait for further keypresses when you hit them.
Additionnaly, Vim's input mechanism is a bit "old school", most probably to keep it consistent over the multiple platforms it may run on. It won't register more than one modifier with a normal key. That means that, if the terminal doesn't eat them up (which it does), you can only do <C-…> or <S-…>. The Alt key is not really a working solution because of how many terminal emulators deal with it and the Cmd key is Mac-only and only works in MacVim anyway.
At that point, if you are ready to mash four keys together to emulate the function of only one key (which in itself is rather silly), you might as well simply use <C-c> which, AFAIK, works everywhere. Your left hand will thank you.
My original question suffers as an XY Problem.
You want to do X, and you think Y is the best way of doing so. Instead of asking about X, you ask about Y.
I wanted to Vim to read Caps Lock as Esc (while still maintaining the other crazy system-level modifications), so I asked about functionality that Vim doesn't have.
Turns out, while the answers provided above were great, on point, and informative, I just don't like being told 'no.' And I was searching for answers in the wrong problem space.
One of the applications discussed in the OP's link, KeyRemap4MacBook, is highly extensible. The documentation leaves much to be desired, but I was able to piece together a solution in line with my original question. This diverges sharply from the original topic of "map stuff in vim," and for that I apologize, but I hope to leave this in posterity for the one poor soul that needs this.
Simply put, the previous article recommends adding this to KR4MB's 'private.xml' file:
<item>
<name>Remap Caps Lock to Hyper</name>
<appendix>OS X doesn't have a Hyper. This maps Left Control to Control + Shift + Option + Command.</appendix>
<identifier>caps_lock_to_hyper</identifier>
<autogen>
--KeyToKey--
KeyCode::F19,
KeyCode::COMMAND_L,
ModifierFlag::OPTION_L | ModifierFlag::SHIFT_L | ModifierFlag::CONTROL_L
</autogen>
</item>
(modified slightly for Caps Lock)
This can instead be changed to:
<item>
<name>Caps Lock to Hyper OR Escape</name>
<appendix>Caps Lock should be remapped to F19 (80) in PCKBH</appendix>
<appendix>This remaps F19 to "Hyper" aka Cmd-Shift-Ctrl-Alt...</appendix>
<appendix>...but, when pressed alone, F19 sends only escape</appendix>
<identifier>remap.hyper2hyper_escape</identifier>
<autogen>
--KeyOverlaidModifier--
KeyCode::F19,
KeyCode::COMMAND_L,
ModifierFlag::OPTION_L | ModifierFlag::SHIFT_L | ModifierFlag::CONTROL_L,
KeyCode::ESCAPE
</autogen>
</item>
This tells the system that whenever Caps Lock is pressed alone, it's actually Esc, but if it's pressed in conjunction with any other key, it's F19.
I've been using Vim for many years and have never really thought about it. A friend of mine asked why that is, noting that in our culture, left would usually map to up while right would map to down, making the Vim keys backwards.
I understand that they are on the home row, meaning that you do not have to move your fingers anywhere to hit them, but that's a different point altogether.
Why were these keys given their present purposes? Is there some documentation on the decision as well?
The answer is in the Wikipedia entry for vi. Bill Joy, who wrote the visual mode of ex - which ended up being Vim's precursor vi - used a Lear Siegler ADM-3A terminal on which the HJKL keys mapped to left, down, up, right - and it’s been that way ever since.
Here's the keyboard layout:
A couple of other points of note on the ADM-3A layout:
Left of the Q: the escape key - somewhat handier than where it is on keyboards today, hence a good choice for switching between normal and insert modes.
Top right: the 'Home' key doubles as the tilde (~), which subsequently became shorthand for a Unix user's home directory.
vimtutor provides the mnemonic that 'J' looks vaguely like a downward-pointing arrow, though that may or may not be the original reason why it was chosen.
This is a total guess, but: The Ctrl+J character is the "line feed" character, which on a traditional TTY moves down one line, providing a mnemonic. K was right next to it on a Qwerty keyboard, under the second most commonly used finger on the right hand when in the home position.
Simply to supplement all the answers, here is the photo of the ADM-3A keyboard (the exact keyboard on which Vim has been created).
P.S: I wish they had used W, A, S, D
From a user experience perspective, after you open a file, you always move down first and moving down is usually a more frequent operation. Since from left to right is the natural direction for most of us, it make sense to associate the task you perform first or more frequently with the key on the left. You can try to switch the 2 keys and try to tell which way is better. For me, "J" for down is more natural and comfortable.
It explains it if you run vimtutor in the terminal. It says:
The h key is at the left and moves left.
The l key is at the right and moves right.
The j key looks like a down arrow.
I always thought it was because on the Dvorak layout, j and k are also next to each other. There are not many keys that have this property on both Dvorak and A/QWERTY/Z.
Bash uses readline, and readline can delete the word to the right of the cursor with "kill-word".
The problem is in recognizing the keypress of control-delete. When I press them in bash, "5~" is output on the screen. I could just bind for this, but it would mean that one day I need to type "5~", and it deletes a word to the right instead! So I'd much rather discover the correct control sequence.
I have googled, and quite a few resources discuss the "delete" key, but none that I've found discuss "control-delete" key. I've experimented with many variations, but nothing works.
The worst is the hours I've spent on this tedious, mindless grind, when it really should be a non-problem.
EDIT: It's through X, so maybe there's a solution with xev and xmodmap
On my machine, pressing Ctrl-V, Ctrl-Delete outputs this:
^[[3;5~
The ^[ escape character can be replaced with \e, so you can then use bind like this for bash (in your ~/.bashrc for example):
bind '"\e[3;5~":kill-word'
Or, you can add the following to your ~/.inputrc so Ctrl-Delete does kill-word in any program that uses readline:
"\e[3;5~": kill-word
This will bind only the Ctrl-Delete key, you don't have to worry about what will happen if you need to type 5~.
What you see is not the whole truth. It's probably <ESC>5~ or something like that. Try Ctrl-V Ctrl-Delete. The Ctrl-V means "do not interpret the next thing".
So binding <ESC>5~ that should be pretty safe.
Alt+D deletes one word to the right of the cursor
Ctrl+W deletes one word to the left of the cursor
(both are based on Emacs, I believe)
If you type ^Q^V (that's Control-Q followed by Control-V, releasing the Control key between them is fine), and then press Control-Delete, do you get the output you mentioned? I just tried it, and at least using Putty I don't get a response at all. Perhaps the behvior is different on an actual Linux console, though.
For other keys, readline prints a longer sequence, often including a special "command sequence introduction" character, which is hard to type by mistake. Try it, and see if you get a longer sequence with the ^Q^V command (which is, btw, called quoted-insert).
For example, if I press ^Q^V and then Delete (without control held down), readline prints ^[[3~. This tells me I can bind stuff to the Delete key by saying \e[[3~. It seems highely likely that the CSI character is present for you, but you're not seeing it since you're not asking readline to quote the input properly.
Ctrl-W deletes words.
Ctrl-u deletes lines.
They're based on Emacs (M-w and M-u).