help-texinfo
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Patrice Dumas
Subject: Re: HTML <title> node names: Not emitting 'Top (Manual name)'
Date: Thu, 14 Mar 2024 22:52:20 +0100

On Wed, Mar 13, 2024 at 09:25:44PM +0200, Eli Zaretskii wrote:
> >   . 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.

I had a look at the code in admin/admin.el that (unless I missed
something) seems to do that, and indeed, it makes extensive changes and
needs to parse specific constructs.  Also it seems that you try to
target a wide range of makeinfo versions output.  I think that we do not
actually try to keep the level of stability of the makeinfo HTML output
you would need to avoid the need to change your code now and then, and
although I agree that we should lean towards stability, I do not think
that we should target that level of stability, because we need to cater
for the needs of all the users, as you already mentionned.

What we envisionned, instead, was to provide with the HTML customization
API to do the kind of modifications you want to do.  I can imagine a
number of reasons why this solution is not that attractive for your use
case, for instance it does not allow to be compatible with a wide range
of makeinfo releases, may not be that stable, is in Perl, and could
require important work.  Still, maybe you could consider using that
possibility in the future if you face incompatible changes again.

-- 
Pat



reply via email to

[Prev in Thread] Current Thread [Next in Thread]