> From: bear <xxxxxx@sonic.net>

    > 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&currency_code=USD

and

xxxxxx@emf.net for www.moneybookers.com payments.