[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:http://en.wikipedia.org/wiki/Backspace>
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
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
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
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
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
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.
Main Index |
Thread Index |