help-texinfo
[Top][All Lists]
Advanced

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

Re: Colons in indices


From: Eli Zaretskii
Subject: Re: Colons in indices
Date: Thu, 06 Dec 2001 23:09:16 +0200

> From: "Robert J. Chassell" <address@hidden>
> Date: Thu, 6 Dec 2001 17:58:53 +0000 (UTC)
> 
> Thank you.  I see how it would be done.  This would enable you to use
> periods in node names, too, but not commas or apostrophes.  (Commas
> are needed to enable you to write an Info file, like the one for
> Emacs, that does not have the form of a hierarchically organized,
> printed book; apostrophes are forbidden by TeX.)

Actually, the Emacs manual pretty much stopped using commas in the
@node lines, but a few auxiliary manuals which come with the package
still do.

> Presumably, you plan to enhance Emacs so that a person writing an
> Info document, or converting a Texinfo document to Info, will be able
> to see (or hear) the separators, as he or she can now, to debug problems.

We could make the links stand out in color, for example.

> For backwards compatibility, we would need:
> 
>     * a program to convert existing Info files, including compressed
>       Info files.

I don't think we need that, the old format of marking the links will
still be supported.

>     * a new minor mode for viewing Info files in GNU Emacs for
>       debugging purposes

Emacs already shows the links in a different face, so they will be
visible even without any special minor mode,

>     * Some way to make sure that people do not inadvertently try to
>       incorporate commas and apostrophes, or @-commands.

This is not necessarily part of this project: it's an existing
problem, and we could leave it alone.

> This is a great deal of work

Not really: all we need to be concerned about, in the Texinfo
project, is to modify makeinfo and the stand-alone Info reader.  The
Emacs project should change the Info mode accordingly.  The rest will
have to be done by the maintainers of the other packages, if they
want to support this feature.

> What are the various downsides to the proposal?

If we go for the null characters, one problem is that it will be a bit
harder to handle the text, since it is no longer a C string.



reply via email to

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