Re: HTML <title> node names: Not emitting 'Top (Manual name)'

Eli Zaretskii <[email protected]> Wed, 13 Mar 2024 21:25:44 +0200
Newsgroups gmane.comp.tex.texinfo.general
Message-ID <[email protected]>
> From: Gavin Smith <[email protected]>
> Date: Wed, 13 Mar 2024 17:30:53 +0000
> Cc: Eli Zaretskii <[email protected]>, [email protected]
> 
> > > Changing such long-standing behavior just because it looks like
> > > "redundant" is not the best idea IME, but if no manuals and no
> > > browsers use this, maybe it's not as painful as I fear it could be.
> > 
> > Note that this behavior has been here since GNU Texinfo 6.4, and is
> > generally good.  I am only proposing altering the 'Top' node (usually,
> > index.html).
> 
> As you point out, the page title changed in that version of Texinfo,
> as before it was like "Using the GNU Compiler Collection - Top" with
> the manual name first.  NEWS entry:
> 
>   . for HTML output, place section names before the manual in page
>     titles, instead of after them, so it is easier to distinguish pages
>     if titles are truncated
> 
> Nobody complained about this breaking any stability.

Ha! the amount of grief those changes caused the Emacs maintainers is
beyond complaining.  We have a script that massages the produced HTML
manuals for the Web site, and we run the script each time another
Emacs version is released and the manual needs to be updated on the
Web site.  Every single release of Texinfo, until very recently, would
break the script and cause me personally and my colleagues a lot of
gray hair wand wasted time.  So much so that I seriously considered to
stop updating to the latest Texinfo on the system where I usually work
on Emacs releases.  Finally, a few Texinfo versions ago, these changes
have stopped, and we had a few Emacs releases without a single problem
in this area.  No longer, it looks like...

And no, I didn't complain, because I never imagined (and don't imagine
now) that someone would seriously consider backing out the offending
changes, just because one project suffers from them.  But you'd be
wrong taking silence for a sign of no problems.

Once again: IME making breaking changes "just because we can" is not
the best strategy for stable projects.  But I'm not a Texinfo
maintainer, so my opinions on this probably doesn't mean much...