[Top][All Lists]

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

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

From: Karl Berry
Subject: Re: address@hidden: RE: cannot find :enable in Elisp manualindex]
Date: Sat, 2 Jun 2007 19:00:10 -0500

Regarding allowing arbitary characters in node names.

It seems to me that neither \: nor SGML entities are a solution.  Either
one involves making normal characters special (\ or &#;), which will
break lots of existing documents.  There are Texinfo documents which
have the literal text "&123;" precisely to document whatever &123; is.

Perhaps I'm missing something, but I don't see how having some simple
HTML-ish output would solve the problem either.  Even if we design and
implement such a thing, Info output will still need to continue to exist
for plenty of years to come, and therefore source documents could still
not use : (or whatever) in node names.  (See also my last paragraph below.)

Using 0xA0 (or any other single byte value) for a quote is not a
solution either, in my mind.  It could have worked if it had been
designed that way from the beginning, but now there are documents with a
literal 0xA0 in the input.  We don't want to break them.

What I think has the best chance of working in the context of the
current Info format is to use the same construct for arbitrary
characters that we already invented for images:
address@hidden src="somefile.png"address@hidden 
(the ASCII ^@ and ^H I'm writing in this email are actual NUL and BS
chars in real output.)

For instance, we could have
address@hidden address@hidden
where xxxx are hex digits.  It would be interpreted according to
whatever encoding was declared for the document.

Existing viewers would obviously just display it literally, which is
ugly, but I don't think it would otherwise break anything, as making new
special characters would.  I can't be certain without trying it, but I
don't think existing viewers would bomb out if this sequence occurred in
a node name.

What happens on the Texinfo input side is another problem, but this
message is too long already.
    But that means there are no faces, no graphics, no non-ASCII
    characters, etc.  

Non-ASCII characters can be included literally, since there is a
provision for defining the character set.

Images can now be included with the construct above.  I believe this
works in Emacs 22, at least I hope so, since that's why it was invented.
A similar construct is used to mark indexes.

One more thought: someone going to the trouble of writing a whole new
viewer might as well use TexinfoML XML for its input, it seems to me (as
Juri wrote).  It exists today (makeinfo --xml) and has been used in a
couple of real projects (e.g., http://www.nongnu.org/texi2latex/).  It
essentially translates Texinfo source into XML syntax, doing a few
Texinfo-ish things like macro expansion and conditionals along the way.
It doesn't make any layout decisions, as Info format does (and must).


reply via email to

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