Re: Arbritary characters (like colons) in node names (proposal)

[Eli Zaretskii]

> Date: Sat, 19 Apr 2014 16:05:47 +0100
> From: Gavin Smith <address@hidden>
> Cc: address@hidden
> 
> On Sat, Apr 19, 2014 at 7:46 AM, Eli Zaretskii <address@hidden> wrote:
> >> Backwards compatibility:
> >>
> >> These would not work in old browsers, but references like these don't
> >> work any way.
> >
> > They don't work as references, but they are still readable.  Your
> > suggestion, which uses control characters, will require the Info
> > readers to remove them from what is displayed, otherwise the text will
> > look garbled on display.  Perhaps using ASCII characters for quoting
> > will ease the compatibility problems during the transition period.
> >
> If (non-control) ASCII characters are used for quoting/escaping, what
> would this look like? There may be some already-existing manual which
> uses a node name which could be interpreted as using these escape
> sequences.

If there is such a manual, it will just make some of its references
fail (if they don't fail already).  But the text will still be
legible.

> I understand that this would look quite garbled, so here is another 
> suggestion:
> 
> q1 = ^?
> q2 = ^?
> q3 = ^?
> q4 = ^?
> q5 = (
> q6 = )^?
> q7 = ^?

That's better, IMO.  I think we already use ^? for different purposes
(in the Tag Table), though.  Not sure if that matters, but see below.

> I.e., no quoting of file names at all, and quoting node names in ^?
> (0xFF) when they contain forbidden characters. I don't think this
> looks too bad.

^? is 0x7F, not 0xFF.

> E.g.,
> "File: quoting.info, Node: Top, Prev: Normal 1, Next: ^?std::cout^?,
> Up: Normal 2"
> 
> for a node line.

Did you try this with Tag Tables?

> > Also, since technically control characters are allowed in an Info
> > file, you will have to come up with a scheme to produce literal 
> > address@hidden(
> > etc. sequences as well.
> 
> I expect there aren't many files which want to present control
> characters by placing the character in the file. There are some cases
> when it won't work (the ^_ node separator for example). When this
> works I think it is mainly by accident.

It's okay not to solve the cases where an Info file use ^_ (I don't
think you will find any of these, for this very reason).  But I don't
think we can just disregard the control characters that do no harm
today, because an Info reader that will try interpreting them as a
quote might do some very wrong things with them, or even crash.  IMO,
if we want the solution to stand the test of time, it should provide
some way of having "harmless" control characters in the file, without
interpreting them as quotes.