I am running elinks (0.12pre5) in an xterm window in Openbox on a Debian netinstall (7.8) with fairly minimal changes/additional software installation. I have changed a few elinks options, but none that seem like they should be relevant to this issue. In particular, I have not changed any of the keybindings. I have installed the terminus-fonts package, on the off chance that that's relevant.

According to man elinkskeys, Alt+< and Alt+> should jump to the first or last line of the current buffer when editing a text box, or move a tab to the left or right otherwise. For me, they do neither of these things. When editing a text box, Alt+< (i.e. Alt+Shift+,) generates the character ¼ (the composed version of 1/4) and Alt+> (i.e. Alt+Shift+.) generates the character ¾ (the composed version of 3/4). I also tried omitting the Shift; Alt+, gives ¬ and Alt+. gives ®. When not editing a text box, none of these keystrokes seems to do anything.

On a possibly related note, the man page indicates that, when editing a text box, Ctrl+A and Home "go to the start of the page/line" and Ctrl+E and End "go to the end of the page/line." In fact, all four keystrokes go to the start/end of a line as expected, but do not move the cursor between lines, even when struck repeatedly or held down. Thus, I don't seem to have any way of moving vertically more than one line at a time within a text box.

Tab and Shift+Tab also appear to do nothing when editing (I don't expect Alt+Tab to do anything, since that's presumably being preempted by Openbox — which I want it to be!). I am not sure whether this is a consequence of my turning taborder off, which I did because it interacts badly with numbered links on certain pages.

  • I started a giant edit to use keyboard escapes and code escapes, but I accidentally refreshed the page and lost all my edits… I don't have the motivation to do it all over again right now; perhaps I will shortly if the OP does not see fit to add them.
    – HalosGhost
    Commented Apr 6, 2015 at 23:38

1 Answer 1


In the old days, men were real men, women were real women, small furry creatures from Alpha Centauri were real small furry creatures from Alpha Centauri, and Anglo-Saxon programmers thought that 95 printable characters and 33 control characters was enough for everybody. Bytes were pretty much 8-bit large all around, but 7 bits were enough for all the characters, so each byte meant to represent a character had a spare bit. Many terminal makers decided to put that spare bit to good use. Terminals often had a modifier key to indicate “I want to invoke a command” as opposed to “I want to type a character”, called Meta. So many terminals used that spare bit to indicate “the Meta key is down”. For example, pressing . sends the byte value 46 (ASCII code of the character .); pressing Meta+. sends the byte value 46+128 = 174.

Then people using European languages wanted to use computers, too. They needed to be able to write in other alphabets, and characters with diacritics, and English and non-English speakers alike wanted to have more punctuation characters. so they designed a number of character encodings that extended ASCII to make use of that 8th bit. For example, in the ISO 8859-1 encoding (a.k.a. Latin-1), the byte value 174 encodes the character ®. On terminals where the Meta key is encoded as setting the 8th bit of the byte value, when running an application that expects input encoded in ISO 8859-1, pressing Meta+. effectively sends the character ®.

Some Europeans started memorizing that Meta+. would insert ®, and that Meta+i would insert Meta+é, and so on. But this didn't help people who didn't want to memorize. Fortunately, there were other solutions, such as national keyboard variants (where the French get a é key, and the Swedes get a å key, and so on), dead keys and compose keys. In any case that solution wouldn't work for the people who wanted more than 256 different characters, such as speakers of most Asian languages.

Meanwhile, another, more common convention to encode the Meta key evolved: have it send the Escape character before the encoding of the key. For example, Meta+. would send the same two-byte sequence as Esc, .. This is what most applications expect nowadays.

Having the Meta key set the 8th bit is a long-obsolete technological decision, but it still lives on in the default configuration of some systems. PC keyboards don't have a key labeled Meta, but they have a key labeled Alt in the same location and with the same expected effect, so wherever you read about a “Meta” key, that applies to “Alt”.

Xterm defaults to having Meta set the 8th bit, for historical reasons. To make it send an Escape character instead, you need to either:

  • set the metaSendsEscape resource to true (there's also altSendsEscape, but it only applies if you've set the altIsNotMeta resource to true, which is only useful if you have both Alt and Meta keys on your keyboard); or
  • set the eightBitInput resource to false (despite the name, this does not prevent non-ASCII input, this only determines what Meta+character sends).

Put either of the following lines in the file ~/.Xresources:

XTerm.VT100.eightBitInput: false
XTerm.VT100.metaSendsEscape: true

Run xrdb -merge ~/.Xresources to reload this file. Most environments arrange to run this command when you start the GUI; if yours doesn't, add it to your GUI login scripts.

You can also toggle the metaSendsEscape resource in the Ctrl+Left-Click menu (“Meta Sends Escape”). This only affects the xterm instance where you use it.

Your other Links keyboard shortcut problems are related to Links, not to the terminal.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .