bug#68970: 30.0.50; Info.el: Info-url-alist should support format-sequence that encodes "Top" node as "index"

[Eli Zaretskii <eliz@gnu.org>]

> From: Mekeor Melire <mekeor@posteo.de>
> Cc: 68970@debbugs.gnu.org
> Date: Wed, 07 Feb 2024 19:52:15 +0000
> 
> 2024-02-07 16:51 eliz@gnu.org:
> 
> > Sorry, I don't think I understand: "https://example.com/" stands for
> > "https://example.com/index.html", AFAIK.  This is why %e produces an
> > empty string for the Top node.  So why would users want to specify
> > "https://example.com/%e.html" instead of just "https://example.com/%e"?
> >
> > IOW, I don't see why users will need to use the .html extension in the
> > alist, it works without the extension.
> >
> > What am I missing?
> 
> Let's assume we have a manual with "Top" node as well as a node called
> "Foo". Let's further assume the webserver is configured so that
> example.com/Foo does not resolve to example.com/Foo.html but rather
> results in "not found".

Why would we assume a strange configuration like that?  That's not
what happens on gnu.org, for example.  Which documentation sites that
offer Texinfo-derived manuals have such configurations?

> This is why the user must choose to use example.com/%e.html as
> URL-specification currently. But then they have the problem that the
> "Top" node is translated to example.com/.html.
> 
> I suggested to add another format-sequence, %i, that translates the
> "Top" node as "index". Thus, example.com/%i.html would translate to
> example.com/index.html in case of "Top".

I understand, but the overlap in functionality between %e and %i is
got to cause some confusion, so if there's a way to avoid that, I'd
prefer it.  The code intentionally produces an empty string for "Top",
and there's a good reason for it doing so.