pika-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Pika-dev] other char/string things


From: Tom Lord
Subject: Re: [Pika-dev] other char/string things
Date: Sat, 24 Jan 2004 19:50:15 -0800 (PST)

    > From: Matthew Dempsky <address@hidden>

    > Tom Lord <address@hidden> writes:

    > > It's been called to my attention that I forgot to specify a "control"
    > > buckybit.  Oops.

    > I recall pointing that out to you and getting a response rationale of
    > something like "control is something special and will be handled
    > elsewhere/differently."  :-P


Yup, I was wrong.  Sorry.

    > > Just for the record, what we eventually need to tweak-things into
    > > is to have:
    > >
    > >         C-
    > >
    > > as a character name prefix, mean to set the control buckybit.
    > >
    > > Thus, 
    > >
    > >         (char->integer #\C-a)
    > >
    > > is some large integer -- not U+0001
    > 
    > That shouldn't be too hard to add.  At the moment it's mostly a
    > non-issue, but since you mentioned sorting on character value (which
    > includes buckybit value) perhaps it would be worthwhile to give some
    > thought to a stable ordering for the buckybits?

Sure.  That's a detailing issue, though.  Nothing should actually
depend on it at this stage.


    > > Additionally, character _names_ (not bucky-like prefixes) are needed 
    > > for ASCII control characters:

    > >         ctl-a           == U+0001
    > >         ctl-[           == U+001B
    > >         ctl-@           == U+0000
    > >         ctl-space       == U+0000

    > > etc.

    > Again, this should be easy to add since the lexing code won't mistake
    > any of those as buckybits.  (Is ctl-space really U+0000?)

Right and (I dunno -- pseudo-traditional kbd behavior there.   No
strong feelings either way.)


    > I can't admit I fully understand the rationale of it, but I'll give it
    > a few days to try to sink in before questioning it.  I said before I
    > had a few other things I was working on, but luckily none of them
    > demand any buckybits allocated to them. ;-)

Rationale: keyboards have buttons that "denote" codepoints.  But they
also have modifier buttons/modes.   Not all combinations of modifiers
and codepoints are codepoints.   Meanwhile, it's nice to have all
those combinations in a form where you can include them in strings and
buffers and so forth (and, no, GNU Emacs isn't up to that -- this is a
small way in which Pika Emacs will be cleaner).

-t





reply via email to

[Prev in Thread] Current Thread [Next in Thread]