NetBSD-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: The Chthulhoid horror that is keyboard handling in Unix (Re: Backspace, Delete and other keys)

Magnus Eriksson wrote:

(not directed at Greg)

On Wed, 31 Mar 2010, Greg A. Woods wrote:

Delete is supposed to be ASCII DEL, which is supposed to delete left.

Ah, that's not MS-Windows fault.  That was a debate started long before
any graphical user interface was ever built.  :-)

See, for instance, <URL:>

There the dilemma is explained as follows:

   In modern systems, the backspace key is often mapped to the delete
   character (0x7f in ASCII or Unicode), although the backspace key's
   function of deleting the character before the cursor remains.

I guess by "modern" the author meant something as new as an ASR-33.  :-)

To those born after the Stone Age of computing, the above doesn't even begin to make sense. "delete character"? It's not a character, it's an operation, it's *something you do*.

Not really. DEL is a character. Deleting a character to the left for you as a user, is something the OS does for you, when requested.

What I mean is this: The up arrow key doesn't send a "move cursor up character"[*], Caps Lock doesn't send the "START SHOUTING CHARACTER" followed by the "toggle led character"; and the power key doesn't send a "turn system off character". "delete character"? April Fools isn't until tomorrow, you know.

No key sends an operation. They all sends codes, which the OS is free to interpret any way it want to. What is there that makes an "a" to echo when you press the key marked "A". It is the OS, which makes that decision. And it can just as well do something else, like decide to move the cursor one step to the right, if it would think that is a good idea.

[*] Although I am sure someone will be glad to point out what VT100 expects...

The VT100 don't expect anything. If you press the key marked with an up arrow, it will send a series of characters to the OS, and what happens after that totally depends on the OS, and the possible application you are running. It could just as well decide to echo an "a" when you press that key.

Before you start, I have already read not only what is on Wikipedia, but also VT100 documentation, Tom Jennings' excellent "Annotated history of character codes", parts of the source of wscons, and have attempted to write a keylogger for X (the horror...) as well as a microcontroller PS/2 keyboard input routine. I know what you old farts are talking about, and some of the reasons why things are as they are; I'm just pointing out that if you take a step back, it all looks pretty absurd here in the 21st century.

No it don't.

And the most absurd thing here is the argument that "the <foo> key is supposed to send the <bar> character". That's just stupid. The user hits the key, and expects the right thing to happen. Whatever happens in between, that's just implementation details. USB or PS/2 keycodes, VT100 emulation, console or xterm -- whatever.

What happens under the hood (and there are a lot of contortions squeezed in for seemingly no good reason) between hitting backspace and seeing a character disappear are not juicy bits of equally-valid choices to be offered to the unsuspecting person in front of the keyboard, that's "stuff I shouldn't have to deal with" and it gets in the way of getting things done. Asking users to set environment variables and mucking around with dot files is the wrong way to go about things, unless the goal is to annoy people.

I totally disagree with you. You have to understand what is going on, in order to decide which way you want it to behave, and then set things up accordingly.

Let me work it backwards for you. You have the OS, which by some convention needs to receive a specific character code in order to delete one character to the left. For some OSes, like Unix, the code for this can be changed, for some other OSes it can not. So you need to know which character is needed, and why. From there on backwards, you then need your terminal to send this code. You terminal sends a code based on a key being pressed down. So you need to know how to get this mapping right, to get the right code sent to the OS.

There is no way you can ignore this middle part of the equation. There are separate entities involved here, which might be computers on different sides of the world, and they need to agree on what convention to use. It's a simple form of a protocol actually. And you are saying that you think we should have to think about the protocol. It's like saying I have this file here, and I want to send it to this other computer, and I don't want to set up a network or anything. It should just work. After all, it's pretty obvious. File. Copy. Transfer. I shouldn't need to know what goes on in between. And yet, you have ftp. You need to know the hostname, or IP address. You need to know if it should be transferred as text or binary. You know what you expect, the computer don't. You need to set things up for it to become right. Just as you cannot either connect an IPv4 machine to an IPv6 machine, and just expect them to talk. They need to agree on the protocol for any meaningful communication to be possible.

So. Your terminal is on one side. And a computer is on the other. Now, these could physically be the same computer, but they could just as well be totally separate. And therefore you must make sure they agree on the protocol, and you need to map your terminal to send the right codes, as assumed by this protocol.

So yes, there are multiple ways of doing this, and they all work. But they are different. So you need to choose. And it might make a difference, because some other machine you might want to talk to might have a different idea, in which case you get into trouble again.

So -- who's with me on coming up with something better than the current mess?

Not me. I wish you luck in trying. However, I'll continue to set up my terminals to send the DEL key when I press the canonical RubOut, since I actually use computers that interpret DEL as meaning delete the character to the left. And I like to keep things consistent, so I do the same for all my Unix stuff. But others obviously want something else, and I'm not going to try to stop them setting things up the way they want to for their use.

And occasionally I'll continue to have headaches with some X programs which mess things up in their attempt to hide the whole deal.


Home | Main Index | Thread Index | Old Index