[Top][All Lists]
[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