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

Reply via email to