emacs-devel
[Top][All Lists]
Advanced

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

RE: address@hidden: RE: cannot find :enable in Elisp manualindex]


From: Drew Adams
Subject: RE: address@hidden: RE: cannot find :enable in Elisp manualindex]
Date: Mon, 28 May 2007 21:01:52 -0700

> > Would someone please DTRT, then ack?
>
> Is this even feasible?  Index entries cannot include colons, it's a
> limitation of the Info format.  The Texinfo manual clearly says not to
> use them.

That's really too bad, if it's the case. Keywords are important things to
put in an index (not to mention the fact that some languages to be
documented might use colons in special ways). If this is really not
feasible, then users are reduced to using search in Info to find a keyword
such as :type, :display, or :enable - pretty primitive (but still far better
than visiting the many "type", "display", "enable" etc. index entries).

Is there no way to escape a colon somehow, so that Info does not interpret
it? The Texinfo manual says that this limitation is because "a colon
separates the menu entry name from the node name, so a colon in the entry
name confuses Info." If there is no way to escape a colon - to let Info know
when a colon doesn't indicate a menu + entry, then shouldn't there be?

Analogy: In Framemaker, colons in index entries are used to create
hierarchical entries, so, e.g., "foo:bar" produces an index entry "foo" with
subentry "bar". You can nevertheless escape a colon with a backslash, so,
e.g., "foo:bar\:toto" produces entry "foo" with subentry "bar:toto".

I haven't used TeX/LaTeX/Texinfo for 20 years, but my memory of LaTeX and
Tex, at least, is of something very powerful and flexible. I'm surprised if
there is no such escape mechanism for Texinfo.

Suggestion: If a user enters a colon at the `Info-index' prompt, print a
message saying 1) that the colon is being ignored, and 2) you can, as an
alternative, use search (`s' or `C-s') to search the manual for a term that
contains a colon. IOW, let users know right away how to work around this
limitation.






reply via email to

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