Thomas Lord wrote:
> I'm afraid I don't understand the distinction you are making
> between characters and keyboard events. Both are captured
> by my Shannon-referring definition of characters. Neither
> keyboard events or 5.92's definition of CHAR captures any
> linguistically robust definition of textual characters. So, what are
> these characters of which you speak?
Keyboard events are mapped (by some event-handling framework)
into commands/actions. Raw keyboard events are key-down and
key-up events, and include "bucky-bit state", a timestamp, etc.
Some of these events translate into "insert" actions: I.e.
map the event into a character and insert that character into
a string (/field/buffer). At that point the character no
longer has bucky bits.
Characters in the sense constituents of a string, buffer, or file,
do not have bucky bits. At least not in any application or
environment or use-case that I know of.
Characters in the sense of something typed on a keyboard may
have bucky bits. But there is in general no direct relationship
between raw keyboard events and what gets inserted into a string
or file. First of course we have to handle down/up events,
translate the state of shift bits, handle the compose key, and
maybe invoke a general "input handler" (for languages like
Chinese).
It is a "type error" to think of input events as characters.
This another reason why the concept term "character" is not useful.
There are "input events" and "strings" and "buffers" (which
are mutable strings). R6RS should not try to standardize
input events, and strings/buffers do not contain bucky bits.
Hence bucky bits are irrelevant to R6RS.
--
--Per Bothner
per_at_bothner.com http://per.bothner.com/
Received on Mon Mar 19 2007 - 14:54:51 UTC