Eli Zaretskii wrote:
>>Date: Thu, 14 Feb 2002 14:26:46 -0800
>>From: Per Bothner <[EMAIL PROTECTED]>
>>
>>>Unfortunately, it's not always practical to request that, given how
>>>many characters we replace with dashes. Think about manuals that
>>>describe C++ classes,
>>>
>>I do. The only characters likely to require mapping are things
>>like 'operator+' and possibly '::'.
>
> No, there are much more characters that are mapped to a dash. `*',
> `/', `^', `.', and many others.
I meant in context of "manuals that descibe C++ classes".
> IMHO, it's no business of makeinfo to force authors to fix their
> manuals due to the file-name clashes. There's nothing wrong with a
> Texinfo manual which has two nodes like ".Foo" and "/Foo". Before
> Texinfo 4.1, such a file would be accepted with no complaint, and
> would produce a valid HTML file. It's IMHO wrong to reject it in the
> next release.
Well, I'm not suggesting it be rejected (though a warning might be in
order when splitting). Leaving out the anchors is not the same as
rejecting. It makes for a minor decrease in redability, but if ".Foo"
and "/Foo" are mapped to the same file but (say) "Foo/" is mapped to a
sifferent file, even though the manual is written ".Foo", "Foo/" "/Foo",
well, in that case the manual is broken, period.
I have another idea, which I'll explain in a separate message..
> The only situations where makeinfo should refuse to produce valid
> output is when the source violates the Texinfo language
Texinfo is not very well-defined as to what are valid node names.
Perhaps we should change that.
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/per/
_______________________________________________
Bug-texinfo mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-texinfo