Wandering Thoughts archives

Some notes on entering unusual characters in various X applications

Once upon a time it was perfectly fine to only type plain ASCII. But these days even people writing in English (like me) have a steadily increasing desire to occasionally write with accented characters, special symbols like right arrows, and so on. As it happens you can do this in X, although how is not entirely easy and natural unless (and until) you do it a lot.

The first thing you want to do is to make some key your Compose key. If you have a Windows key or two on your keyboard, they make a handy donor key for this purpose and you can set this up with setxkbmap:

setxkbmap -option compose:rwin

This makes my right Windows key into a Compose key.

The basic use of the Compose key is to either tap or hold it and then enter a two-character sequence to get some unusual character. You might ask 'what two-character sequence gets what', and that is a good question. X being X, and Gnome being Gnome, people have made this complicated.

For normal X applications, which I believe includes KDE applications, all of the available key sequences are defined in a Compose file. The standard default file is /usr/share/X11/locale/<locale>/Compose, where the locale is, for example, en_US.UTF-8. You can also have a personal version of this file as $HOME/.XCompose, which may be useful if you want to add additional characters or shuffle things to be more useful. One example of this is this Github repo. Wikipedia also has a guide of common compose combinations.

As covered in the Ubuntu wiki page on the Compose key, GTK-based applications are gratuitously different by defaulting to a hard-coded list that is derived from some version of the default X Compose file. This is probably going to be the same for most common keys, but obviously it'll differ if you have a custom .XCompose file. You can apparently force GTK to use the normal X mechanism if you want, although I haven't tried this.

One advantage of sticking with the default GTK setup is that GTK will then let you directly enter Unicode code points. How this is done is described on the Ubuntu wiki page, although not all GTK applications in all environments will display any indication that this entry mode is active. Having tested it, I can say that this works in Firefox and in gnome-terminal. Unfortunately this is GTK only; it doesn't work in KDE or in general X applications, although there is an upstream bug on this. Don't hold your breath, though.

(Some X applications may have specific support for Unicode code entry and other frills, but you'll have to check their documentation and then maybe experiment to see if it works for you or if it clashes with some other part of your environment.)

Given the GTK situation, my conclusion is that I don't want to bother trying to customize a Compose file for my own use. If I do start wanting unusual special characters on a regular basis (and thus a custom .XCompose), I expect I'll force GTK to use the standard X mechanism and live without the ability to enter Unicode code points. Since I didn't know about it until recently and haven't actually used it, I doubt I'll miss it very much.

(See also this and this.)

Getting xterm and modern X applications to do cut and paste together

I was all set to write a somewhat grumpy blog entry about getting xterm and Chrome to play nice with each other for cut and paste when I decided to re-test this systematically. Let me tell you, systematic testing and investigation changes quite a lot of blog entries around here, and this one appears to be no exception.

The basic background on this is that X basically has two levels of cut and paste, which I'll call a casual level and a serious level. The casual level is making ordinary selections and pasting them with the middle mouse button (in most X applications), while the serious level is done through explicit Copy and Paste actions, generally found in menu entries. In X jargon, the 'casual level' is the PRIMARY selection and the 'serious level' is the CLIPBOARD selection.

(The history behind why both of these exist is long and tangled and basically goes back to the history of cut and paste in X and xterm's different cut and paste model.)

Xterm works fine at the ordinary selection level. Selections you make in xterm can be pasted into modern X applications like Firefox and Chrome, and selections that you sweep out in Chrome or Firefox can be pasted into xterm. But if you look at xterm, you will search in relative vain for a Copy or a Paste menu item. Modern terminal programs like gnome-terminal have entries right there and they do what you expect, but xterm does not.

There are two ways to get Copy in xterm. The first is the confusingly named 'Select to Clipboard' entry on the xterm menu you get with Control-middle mouse button; this makes all of your ordinary xterm selections be Copy-level selections instead of ordinary selections (ie, CLIPBOARD instead of PRIMARY, hence the name of the menu item). You can no longer paste them into most other things with the middle mouse button, but you can Paste them. The second is to add a keyboard binding for Copy in your X resources:

XTerm*VT100.Translations: #override \
     Ctrl Shift <KeyPress> C: copy-selection(CLIPBOARD)

The advantage of a keyboard binding is that regular selection stuff continues to work as it normally does; you just explicitly invoke the Copy operation whenever you need it. Among other things, this means you don't have to remember the 'Select to ...' mode that any particular xterm is in (or forget and be puzzled about why you may not be able to middle mouse button paste a selection in one xterm into something else).

Getting Paste in xterm is much more confusing, so I will give you the conclusion; if you want a real Paste, you need to add another keyboard override:

XTerm*VT100.Translations: #override \
     Ctrl Shift <KeyPress> C: copy-selection(CLIPBOARD) \n\
     Ctrl Shift <KeyPress> V: insert-selection(CLIPBOARD)

Xterm tries very hard to do something smart when you use the middle mouse button to paste things. As part of this smartness, it normally pastes the basic selection from whatever program has one; however, if there is no basic selection at the moment and there is a Copy-level selection, it will paste that instead. The time when you need an explicit Paste operation (as provided here with Shift-Control-V) is when the basic selection is different from what got Copy'd and you specifically want to paste the Copy'd stuff.

(In the jargon, xterm normally tries to paste the PRIMARY selection but if that doesn't exist, it's willing to try the CLIPBOARD. Our new key binding does an explicit insert from CLIPBOARD.)

The old-fashioned and modern ways to remap keys in X (some notes)

As I mentioned recently, I've been remapping my keyboard in X for a very long time. In all of this time, I've been using the traditional and now old fashioned way of doing this, namely xmodmap. Xmodmap is now a deprecated mechanism, although it still works; these days you usually want to be remapping keys with setxkbmap.

You might wonder why X has two different programs for this. As you could guess, it's the usual reason; X added a new system for handling keyboard remapping without removing the old one (because X never removes anything). Xmodmap uses the old system, which I believe has been in X since at least the start of X11, while setxkbmap uses the new system, the X KeyBoard extension.

(Well, 'new' is relative here. XKB apparently dates from 1996, almost two decades ago. I was a little bit surprised to find that out, since I hadn't heard of it myself until recently. This is probably the hazard of having become set in my X ways a very long time ago.)

I'm not the right person to write up a big evaluation of the two mechanisms against each other, because up until recently I hadn't looked into XKB and setxkbmap at all (and even now I only know a bit). So from my limited perspective, the big difference between the two is that xmodmap offers relatively simple and direct low-level control for weird operations while setxkbmap gives you simple ways to do most of what you often want, provided that you can work out the right arguments.

To show what I mean by this, here is more or less the xmodmap magic needed to swap Backspace and Delete keys and to make CapsLock act as a Control key:

keysym BackSpace = Delete
keysym Delete = BackSpace

remove Lock = Caps_Lock
keycode 0x42 = Control_L
add Control = Control_L

You put this in a file and then run 'xmodmap FILE' and magic happens.

By contrast, here is the setxkbmap command needed to make CapsLock act as a Control key and make the right Windows key act as Compose:

setxkbmap -option ctrl:nocaps -option compose:rwin

You will notice that I have not shown you how to swap Backspace and Delete with setxkbmap. That's because that particular change is not among the predefined changes that XKB supports and once you venture outside of those predefined changes, things become rather complicated.

(The predefined changes themselves are documented in the xkeyboard-config manpage. The files that define what these options and so on mean are all found under /usr/share/X11/xkb; see for example /usr/share/X11/xkb/symbols/ctrl. If you look at these files, you'll see that XKB configuration is, well, intricate.)

Because setxkbmap fits my needs right now (now that I'm not swapping Delete and Backspace) and because it's apparently the more approved-of way these days, I've switched from xmodmap to setxkbmap. I probably would not have changed over if I was doing anything that setxkbmap couldn't handle through its existing options for -options; while more sophisticated things are possible, they appear to be a lot of work.

The ArchLinux wiki has some nice references on Keyboard configuration in Xorg, xmodmap, and the X KeyBoard extension. While I accumulated a bunch of additional links while I was looking into setxkbmap, I'm not going to put any of them here because I don't know enough to assess their quality and whether they're up to date.