On Tue, 2009-09-22 at 08:43 +1000, Andrew Reilly wrote: > On Mon, Sep 21, 2009 at 08:49:03AM -0700, Thomas Lord wrote: > > I don't think so. For example, I like the idea > > of using codepoints with buckybits as the names > > of keyboard events. > > Isn't that a fairly gratuitous example of an ad-hoc storage > optimization
No. It's not about storage optimization at all. It's about letting people write keysequences as string literals and manipulate them using string operations (like string<?, string<-ci?, upcase, downcase, substring, etc.). > for a very specific application, It is a fairly specific use but it is not application- specific. We can make other examples very different in character, if you like. > and therefore > not much of an argument for putting something into "thing-1"? > (Where do you put the bucky-bits when the input is EBCDIC? Nobody is talking about "putting bucky-bits into WG1 Scheme" per se. You would put bucky-bits into EBCDIC by using fat codepoints and putting them in the high bits, same as in Unicode. > What's the codepoint for "F11"?) For that matter, what is the codepoint for, say, the down transition of a left mouse button? Traditionally, function keys like "F11" have been handled in a variety of ways. In GNU Emacs these days, a keysequence can be either a string or an array that includes a mix of characters and symbols. Symbols are used for keys like F11. The names of the symbols are significant - for example, S-F11 parses as a shifted version of F11. In the days of yore, function keys on terminals typically generated peculiar sequences of other (non-function-key) characters. In some situations, precisely what sequence was generated could be reprogrammed by the user. There was talk, in the past, of adding function key codepoints to Unicode. I suppose there may be such talk in the future as well. One could, of course, assign them to codepoints in a private use area. One could assign them -- not too implausibly -- to Unicode's circled numbers (U+2460 onward). > > It's a parsimonious choice > > because it gives me a human-friendly print/read > > syntax for individual events and sequences of > > events. > Aren't keyboard events delivered through some sort of GUI > callback these days? Humans have to specify their preferred keybindings in many systems. > > I can sort a set of strings representing > > key sequences using string<?. Compare two for > > equality using string=? or string=-ci? Take > > substrings. Concatenate strings. Even upcasing > > and downcasing are useful. > > How do any of those work when the "characters" have been > peppered with bucky-bits? For example: Assuming your characters use Unicode codepoints as the underlying unmodified character set, then they work by extension of the unicode rules. For example, the upcase M-x is M-X. Of course, the shift-modified version of M-x is (in my preference, its a minor issue) S-M-x which is distinct from M-X (but which most keyboard set-ups can't generate). > Sorry about all the questions: I have never needed to code an > editor (or anything much that had real-time keyboard input), > so I don't know the issues. My intuition says that anything > being pressed by a human is happening slowly enough and few > enough that no effort on space or time optimization (of the > keystroke recording) can be necessary. I suspect that you are not an Emacs users or at least that you don't customize or write extensions for Emacs. A very common situation is having a start-up file that sets key-bindings. Here are two of mine: (global-set-key "\M-&" 'interactive-background-command) (That's Emacs lisp, not Scheme.) That helps to illustrate how it is convenient to humans to write these things as strings. And, here's one I notice from a famous Emacs lisp extension package called "calc": (define-key calc-mode-map (format "r%c" x) 'calc-recall-quick) Notice that FORMAT - a procedure for formatting strings - is being used to generate a particular keybinding in a systematic way, automatically. -t > Cheers, > _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
