Re: bad relative urls in texinfo-4.0f

[Eli Zaretskii]

On Wed, 30 Jan 2002, Per Bothner wrote:

> It used to be that relative links would appears like:
> Up:<a rel=up href="XML-tools.html">XML tools</a>
> 
> They now appear as:
> Up:<a rel=up href="XML-tools.html#XML%20tools">XML tools</a>
> 
> The extra anchor references "#XML%20tools" are redundant and ugly.

Can you tell why ``ugly''?  Those links are never displayed to the user, 
they are for the browser's internal consumption, so their ugliness 
shouldn't matter, I think.

And they are not redundant, even when there's only one node per file: the 
file does not begin with the node text, so the direct link to the anchor 
makes sure you land on the text, not on the preamble.  One problem this 
fixes are the references to the Top node (which is on the same file as 
the TOC): in the previous versions, if you choose the link to Top, you'd 
land on the TOC instead.  Similar problems existed with the short TOC, 
which didn't work at all before this change.

> I can see that they are needed when there are multiple nodes on
> a page but I see no reason for them when referring to the
> main or only node on a page.

The problem is that makeinfo doesn't know whether there will be one or 
mode nodes on that file.  When the HREF anchor is generated, it could 
well be that the node pointed to was not yet processed at all (a forward 
reference); given the possibility of file-name clashes between several 
nodes, makeinfo has no idea how many nodes the file XML-tools.html will 
eventually harbor.

Even for nodes which were already processed, the information about 
whether they are alone on their file does not exist, and is not very easy 
to compute.  We could probably make another pass after everything is 
finished, and remove those anchors from links to files that have only one 
node, but is the problem really worth the slow-down and complexity of 
another pass?

> The main reason I switched from texi2html to makeinfo --html is
> because the latter gives me stable and meaningful URLs.

Yes, support for split-HTML that doesn't break when references between 
different manuals are used is one of the few main improvements in this 
release (in 4.0d this was broken in several ways).  The solution is 
indeed quite complex, as it has to support several marginal cases, like 
documents written for HTML only, but I think the result is quite usable 
and stable.  Of course, if you have suggestions for making it better yet, 
please tell.

> This buglet doesn't quite break that, but it does detract from it.

Is the ugliness of the %20 thing the only problem, or are there others?