[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Colons in indices
Re: Colons in indices
06 Dec 2001 18:00:11 +0100
Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Civil Service)
>>>>> "Robert" == Robert J Chassell <address@hidden> writes:
Robert> Currently, in Info, a colon marks the end of the entry in a
Robert> menu. An index is a long, automatically alphabetized menu.
Robert> If you change Info, what do you plan to use in place of a
Karl sent long ago the following mail, precisely addressing these
Subject: node name restrictions
Hi Richard, Bob, Brian, everyone,
Eli Z. and I have been discussing some ideas for eliminating (almost)
all restrictions on node names. As you know, there have been frequent
requests for : being allowed, especially, for the sake of being able to
have nodes like class::method, a standard sort of OO syntax.
Anyway, Eli had an idea that seemed pretty sound to us, but we wanted to
get the advice of you all before plunging ahead with it.
The basic idea is to replace the colon, period and comma as characters
which delimit a node name with another sequence. For
example, a menu entry will look like this:
* Foo item: ^Foo node^
or like this:
* ^Foo node^::
where `^' stands for the new delimiter.
Then, we change the info readers to look for that new delimiter and
simply omit it when writing to the screen.
For the actual delimiter character sequence, perhaps address@hidden@ would do
nulls). I'm sure there is no node name in existence that begins and
ends with two nulls. Another possibility is SPACE BACKSPACE, which
would probably be invisible in most cases even if it did get written to
the terminal, but that seems somewhat more ambiguous to parse. In
theory it might be better to use CTRL-_ (already a special character in
info files), but that seems like it would cause gratuitious trouble when
old info readers read new info files (which inevitably is going to happen).
Since all of this affects only info files, TeX won't have to worry about
them. TeX has other restrictions (not allowing ' being one), but I
think that won't be much of a problem. At any rate, the characters
people really care about, like :, should pose no problem for TeX.
This is obviously a significant change to info format, and it will
affect all info files generated, unlike our previous change with
@anchor, which people could avoid if they wished simply by not using
@anchor. However, the advantage of being able to use all normal
characters in node names seems significant enough to warrant it, in our