Control, escape, and meta tricks | Hacker News Reader

Control, escape, and meta tricks

susam.net

129 pointssusam17 comments

Some of this is not quite right, or right by accident of a particular virtual terminal's features and configuration.

Having the Alt/Option modifier send a prefix ESC is usually a terminal configuration option, though often the default. The most common alternative (other than doing nothing) is to set the 8th bit, which was useful in the ISO8859 days but not so much with UTF-8.

The vim section of this article depends on the prefix-ESC behaviour, but vim and neovim (and probably other non-ancient editors) will put a capable terminal into modifyOtherKeys mode. In this state the terminal sends a more detailed escape sequence for modifier key combinations, which permits binding combinations that are not distinguishable in the default ‘plain ASCII’ mode. For example, Control-D will send ESC [ 27 ; 5 ; 100 ~ while Control-Shift-D will send ESC [ 27 ; 6 ; 68 ~ (rather than EOT for both) and Alt-D will send ESC [ 27 ; 6 ; 68 ~ rather than ESC D.

(Oddly, the author seems to use vim as an editor but emacs editing mode rather than vi editing mode in the shell.)

The ‘special case’ control combinations are explained by the https://en.wikipedia.org/wiki/Bit-paired_keyboard where Control does merely flip a bit, originally electromechanically.

> (Oddly, the author seems to use vim as an editor but emacs editing mode rather than vi editing mode in the shell.)

I do the same. I gave vim bindings a try in my shell, but I just couldn't get the hang of it. I think vim excels when you are editing multiple lines. And, I can always get to vim to edit the commands if things are getting nuts with Ctrl+X Ctrl+E.

Funnily, these days the first thing I do when I start typing at someone else's terminal is "set -o vi". I cannot function effectively without Vi mode in my shell :)

> or right by accident of a particular virtual terminal's features and configuration

This is a fair point. Indeed different terminal configurations can produce different results. I have added a little note to my post to clarify this. Thanks for the feedback.

> Oddly, the author seems to use vim as an editor

I use Emacs.

> The ‘special case’ control combinations are explained by the https://en.wikipedia.org/wiki/Bit-paired_keyboard where Control does merely flip a bit, originally electromechanically.

I don't think this explains the special cases in a general sense. Firstly, the Wikipedia article discusses shifted keys, not control codes. Secondly, the special cases still need to be explained on a case-by-case basis. It is clear that the control modifier flips a bit but which bit? In case of ctrl+@, ctrl+g, ctrl+h, etc. the 7th LSB is flipped. In case of ctrl+space, the 6th LSB is flipped. A more general rule that covers most of the cases is that the ctrl modifier resets the 6th and 7th LSBs. The exact implementation details, however, vary. As an aside, all of this still leaves how ^? represents DEL in stty and in other contexts requiring printable forms of control characters as a special case. In this case, again, we need to flip the 7th bit. Further, the fact that DEL (decimal 127) is a control character is itself a special case because it is the only control character that has its higher bits (6th and 7th LSBs) set.

The original 1963 ASCII was upper-case only, so it's a mistake to think of Control as modifying lower-case letters. (It also had slightly different control character assignments, and ↑ ← rather than ^ _ for 0x5E 0x5F, but those don't matter here).

Control consistently toggles the 0x40 bit — so Control+A = 0x40^0x41 = 0x01 and Control+? = 0x40^0x3F = 0x7F = DEL. Of course, ? is typed as Shift+/. Shift consistently toggles the 0x10 bit: Control+Shift+/ = 0x40^0x10^0x2F = 0x7F = DEL. This is why on upper-case-only bit-paired keyboards, right down to the Apple II, you type Shift+P = 0x50^0x10 = 0x40 for @. The manual for the ur-ASCII Teletype Model 33 is explicit about how this works in the keyboard section.

Applying this to space (note Shift+0 is space on a bit-paired keyboard) would give you 0x60, which is out of range for 1963 ASCII. Evidently some early terminal decided this should wrap around to 0x00. (The TTY 33 didn't do this, since it's too complicated to do mechanically.) I had not heard of this before, and always used Control-@ (0x40^0x40 = 0).

Incidentally DEL isn't a control code per se. It's 0x7F because a set bit is a hole on paper tape, so it's the only code such that punching DEL over any another code always results in DEL.

Thanks for the detailed response. I was aware that early keyboards were uppercase only which results in the bitwise operation for ctrl key being applied to the ASCII code of uppercase characters only. I too use ASCII codes of uppercase characters only in my post although I write the key sequence in lowercase, e.g., ctrl+g along with decimal 71 as the code of the modified character.

However, I was not aware that '@' was shift+p in bit-paired keyboards. This revelation resolves a few other mysteries for me, so thank you for sharing this bit. Indeed https://en.wikipedia.org/wiki/File:TTY33ASR.jpg shows '@' on shifted 'p'. I do see now how ctrl consistently toggling the 7th LSB explains all the control codes in the ASCII chart. So it is only ctrl+space that sticks out as a special case.

that's all rather, heavily dependent on lucky combination of at least 2-3 mappings - what 1) X-server/graphical-env converts your keyboard into, then what 2) console/terminal converts that into, and then what 3) app (vim or bash or whatever) running inside terminal, decides to map (and there maybe more layers before, inside, after or instead of these - e.g. hoping 0) kernel transparently passing stuff to 1). e.g. If running without X/graphics, then first is replaced by kernel's keyboard processing ; or if running graphical Vim, then 2+3 are replaced.. (ah, and the dual/multi mode-ness of vim adds extra layer inside it - making say ctrl-U to do undo always isn't that easy)

Each of those layers can vary, in different distro's, terminals, versions of same thing, etc. Especialy each and every (X-)terminal-thingie having different idea of how to map (or not) ctrl-F2. Some of them going back to the 197x ..

i have tried to make myself a one-mapping-fits-all (say, pressing F2 does ls -alF in terminal+shell, and saves-the-buffer in vim, no matter what/where/when), collecting variants and combinations for last ~25+ years - incl. linux-console and even dos mapping.. and it works mostly.. but still, no silver bullet.

see the qini/ folder in

https://github.com/svilendobrev/svd_bin

everything may be remapped to your liking.. eventually. YMMV.

ciao & have fun

Interesting to know, but the very notion of control characters seems very odd to me, there's no typewriter or printer with a bell around anymore. Will we ever get rid of this?

It's nice to have in-band signalling in addition to out of band.

Ctrl-G still beeps your console doesn't it?

It doesn't on mine and I'm not sure why.

Many terminal emulators have a config option to disable audible bell.

Some have the option to replace it with a "visual bell".

Some terminal emulators on PCs beep the PC speaker, rather than play a sound through the (high fidelity) audio device. But many PCs no longer have a PC speaker; one way to get a visual bell if the PC speaker output is used, is to connect the power LED to the speaker pins. Makes the power LED a lot more useful too.

I remember speakerectomy being a thing circa 15-20 year ago, to reliably get rid of the console beep.

Most MB still have speaker connections, just have nothing connected to it by default. A couple of years ago I bought a speaker off Amazon (actually a pack of 12 for 1£ as that was the minimum order) just to decode the POST beep when troubleshooting some overclocking issues. Of course I promptly removed it when finished.

> Of course I promptly removed it when finished.

Why? Which issues was it causing if you have the visual bell option in your terminal?

Sadly I checked that and it still doesn't work. I'm using guake on mint.

On Linux the terminal is probably using the X11 bell, and many/most distros don't bother to hook that up. On Debian 12 you need to install `libpipewire-0.3-modules-x11` and `systemctl --user restart pipewire.service` for minimal functionality (`xset b` doesn't work).

Reply on news.ycombinator.com