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. -- Pat
