Re: ":" in Scheme names.

[Eli Zaretskii]

On Mon, 4 Nov 2002, Aubrey Jaffer wrote:

> assuming there is some legacy issue
> preventing info readers from considering only the last ":" in an index
> line as the separator

This was considered and rejected.  We cannot use this logic because 
different Info readers use different methods to find ``the right'' 
colon.  Some use regexps, others use literal character search, some do 
it left to right, others the other way around.  So each one of them fails 
in different ways on some entries and works with others.

> Putting a TAB character after the ":" in index entries in .info files
> does not screw up indexing for the info (4.1) program or emacs (21.2).

There's more than just 2 Info readers out there.  We shouldn't break any 
of them.  (Although I don't think any amount of whitespace after the 
colon will break any of them.)

> The next version of makeinfo would put tabs after ":" in index
> entries.  New versions of info readers would treat ":<TAB>" as the
> separator if present; falling back to ":" if tabs are absent.

Thank you for your suggestion.

However, I don't think it will work to rely on whitespace after the colon: 
whitespace is generally ignored by the Info readers when they look for
node names and other keywords.  Likewise, TABs and SPACEs (and newlines as
well) are treated the same.  These assumptions are buried deep inside the
low-level search routines of the Info reader, which don't really know
whether they are looking for an index entry or something else, so it's not
easy to change that.

As an example, consider this entry from my DIR file:

 * mkfifo: (fileutils)mkfifo invocation.         Create FIFOs: (named pipes).

There are two colons with whitespace after them here; how do you tell 
Info which one to take as the significant delimiter?  The part to the 
right of the node name is free text, so anything can go there.

As Karl said, this is a hard problem, and it's not limited to the colon 
(a period has similar problems here).  There's a strong desire to find a 
solution that would be back-compatible, but I suspect that the solution 
will be more complicated than just adding a TAB.

Thanks again for your suggestions.