On Sat, 2007-08-25 at 17:39 -0500, Aaron Konstam wrote: > On Sat, 2007-08-25 at 17:24 -0500, Mikkel L. Ellertson wrote: > > Aaron Konstam wrote: > > > > > > It seems to me that there is a point that is being missed. What you type > > > on the keyboard is just a continuous stream of characters. A line feed > > > which you get in Linux when you hit return is just a character like any > > > other. When you hit a g the letter g is printed. When a text editor is > > > analyzes the line feed it knows to go to the next line. When the shell > > > sees the line feed it knows it is to treat everything on the line up to > > > the line feed as a command. No magic is involved and it is really very > > > simple. > > > > > It is on an even lower level that that - when you hit a g, a g may > > or may not be printed, depending on what is being done with the > > input. (For example, if I am playing a movie with mplayer, f toggles > > full screen mode, but is never printed.) Now, there are some > > libraries that make thing easy for the programmer. The reason that > > the editing keys work the same in so many programs is that they are > > using the readline library routines. (man readline) > > > > You also have all the terminal control characters that can come into > > play, depending on the interface and settings. (man stty) > > > > Mikkel > Ok, I went too far. Whatever program contols processing the keyboard > input uses anything typed in the way it wants to use it. The point is > that lf is not unique in that regard. > -- Except the keyboard produces 0x0d for the enter key (carriage return or C/R). The Unix or Linux software translates that to linefeed (0x0A). Some systems use (0x0d) to terminate lines, some use (0x0a 0x0d), some use (0x0d 0x0a) and some use these with the msb set. These are stored in the true literal text files, such as those produced by ed, edline or vi. Other word processors may treat them differently. Some use 0x0a to terminate a line, 0x0d or 0x8a to terminate a paragraph, and some use one of the embedded device controls of the ASCII set to control the paragraph or set editor appearance tools (such as the tab ruler, margins, header, footer, page number and so forth). How keys are handled are functions primarily of convention, where most of the conventions in English came from typewriters, just as the convoluted keyboard did. Other conventions came from early word processors, and some came from user experience, where the choice of how to access menues and controls led to simpler key combinations for common actions. Yet other conventions came from the unique capabilities of computers, such as the control keys, which allow accessing the serial bus control commands (note that the serial port on your computer is actually a bus for controlling peripherals as well as an input medium). Still more came from advances in technology, like the command key or the function keys, and lately the keys for controlling sound or other dedicated keys. Again, these grew out of the need for common actions to be accessed in a simpler manner by the user. Keyboards, continue to evolve, and new means and standards are probably going to emerge over time, as language, and systems use continues to evolve. Even the mouse was originally designed to evoke key strokes for its actions, and while mouse technology has evolved, the serial bus and its operation is still the medium of communication that has set the standard, although the mouse itself is now either connected wirelessly, by light or by usb. The mouse has grown buttons, scroll wheels accelerometers, feedback, and eliminated the ball, but the communications system is still "standard" to the serial port capabilities. At least in most cases. Key mapping using a piece of middleware allows systems cross functionality, simplifies some operations and can even be set to interpret key stroke combinations to create more complex functions, as well as add the ability to create more accessibility for our handicapped users, or enhanced capability for those with great artistic bent in some unforeseen direction. All of this is due to hackers, who looked at what was, saw what could be and then worked to fill the gap. OK, not all hackers are good guys, but most are. We benefit every day from them, from Mr. Diesel, to Mr. Ford, to Dr. Robert Godard. Even Tesla was a hacker and proud of it. Regards, Les H
