This page is part of the web mail archives of SRFI 50 from before July 7th, 2015. The new archives for SRFI 50 contain all messages, not just those from before July 7th, 2015.
> From: bear <bear@xxxxxxxxx> > I think I should mention that I regard it as a mistake to > standardize anything relating to buckybits. While I'm providing > them, I'm providing them as completely harmless chrome that > makes no keystroke or representation presumptions or > requirements. I should point out that: 1) I've drafted a buckybits spec orthogonally to everything else: implementations can adopt all of the Unicode stuff and skip buckybits; implementations can adopt buckybits and ignore all the Unicode stuff. (They are interesting to think about in the same context, though, to be sure that neither logically precludes or depends upon the other.) 2) The buckybit proposal is clearly not for all implementations. My rational for providing it could be paraphrased as: ~ some implementations want to be used as extension languages ~ some applications will want to use the keymap/buckybit interaction style of emacs along with a Scheme extension language (and many applications _should_ want this :-) ~ much of the keymap/input-handling functionality of such applications will overlap: it is desirable to support a situation in which extension libraries (of Scheme code) port between these applications, even if the applications are using different implementations of Scheme ~ the buckybit draft is a necessary step towards such standardization ~ the buckybit functionality of Pika Scheme is being built Right Now -- so this is a good time _not_ to submit the draft buckybit SRFI, but to make it available in public in order to solicit design review > FWIW, I'm using the upper 11 bits in string representation to give the > index (relative to the start of the buffer) of the character to which > the codepoint belongs. I'm using it in the first codepoint of my > primitive character representation to say how many codepoints are in > this character. > (Technically, this means my character set is not, after all, > "infinite." It is limited to characters which can be expressed in > 2047 unicode codepoints or fewer.) I think that you're implying "and therefore, I couldn't implement your version of buckybits" but I don't see that. Could you not model (my style of) buckybits by defining a set of 31 private-use codepoints to represent all the non-empty sets of buckybits and then treat those 31 codepoints as a combining character? So, since your CHAR? type is a combining character sequence, #\C-M-x would be the codeponit sequence: <LATIN SMALL LETTER X><PRIVATE COMBINING BUCKYBITS C-M> -t ---- Like my work on GNU arch, Pika Scheme, and other technical contributions to the public sphere? Show your support! https://www.paypal.com/xclick/business=lord%40emf.net&item_name=support+for+arch+and+other+free+software+efforts+by+tom+lord&no_note=1&tax=0¤cy_code=USD and lord@xxxxxxx for www.moneybookers.com payments.