On Sat, Jan 07, 2023 at 11:41:36AM +0100, Torbjorn SVENSSON wrote:
If this is clear that I should have been using the
CASE_INSENSITIVE_FILENAMES setting, why is it not always active?
Because it produces suboptimal manuals in case sensitive filesystems.
I, as a user, would expect to have the same documentation generated
regardless if I happen to run makeinfo on a Windows host or a GNU/Linux
host. Doesn't that requirement make sense to you?
There needs to be a balance between producing filesystem independent
manuals and poducing best manuals. In the default case, we prefer to
produce the best possible manuals. However, you can always set
CASE_INSENSITIVE_FILENAMES if you value more manuals that are better
suited for case-insensitive filesystems.
Indeed, I think that it should be in a more specific place, stating
something clearer about redirection file, for instance that a
redirection file cannot be created for @node XX because @anchor YY (or
@float label) is already associated to that redirection file. Another
even more involved solution would be to remove the automatic redirection
when there are two nodes redirected from a redirection page, and only
leave the text for the user to click on. Or use javascript to do the
redirection, and without javascript there would be a need to click on
the appropriate link.
I can buy the idea of not having an automatic redirect in the case of a
conflict. Would you like me to try to write a patch for that scenario?
That'd be nice, indeed. Beware that the issue can happen between
redirection pages, and also between regular elements and redirection
pages (but not between regular elements).
In the newlib case, there were a chapter (Iconv.html) and a node
(iconv.html) and the solution that "fixed" the problem was to rename the
chapter. I suppose this is also a problem in the current implementation of
text2any as it's simply pushed to the user to resolve rather than having the
tool generate unique filenames/aborting in the case of conflicting
filenames.
I do not think that the tool is to blame (after the bug is fixed, of
course ;-), the decision is to blame. But there is no decision that
is not pushed to the user as there are conflicting choices without a
an option that is better in all cases. If the default was
CASE_INSENSITIVE_FILENAMES=1, all the users who want the best manuals,
on case-sensitive filesystems would have to override the default.