On Mon, Mar 03, 2025 at 06:09:31PM +0000, Gavin Smith wrote:
> On Sun, Mar 02, 2025 at 10:27:39PM +0100, [email protected] wrote:
> > We should have a way to change the format if needed. We cannot have the
> > same format forever if it is not adequate.
>
> The htmlxref.cnf format is good enough for what it does. As far
> as we know, we do not need to add any information about node name
> transliteration to the htmlxref.d files distributed with Texinfo.
> So it is an issue that only affects people who need to use their own
> htmlxref.d files.
Ok.
> Users could put the HTML xref data for the affected manuals in a separate
> file - then they can easily be removed if not needed. Only those files
> would contain the lines like
>
> hello type translit
Should I implement that? We do not necessarily need to do it now, we
could wait for users demands.
What I plan to do is:
* name for links to external nodes is the default one independently of
customization variables. If users ask for it, we can add to htmlxref
hello type translit
* name for redirection files is the default one independently of
customization variables
* if TRANSLITERATE_FILE_NAMES is set, additional redirection files
with translitarated file names are produced, similar to
ADD_TRANSLITERATED_REDIRECTION_FILES, but not as a temporary
measure
> The only other factor I am aware of for HTML xref stability is the
> BASEFILENAME_LENGTH variable, which is unlikely to be used.
Agreed. However, the fact that there is a limit could lead to the same
issue as transliteration with @anchor ending up in the same redirection
file. In what I propose above, BASEFILENAME_LENGTH would not be used to
determine names for cross references and names for redirection files,
only names for locally generated files.
Is the plan above ok?
> > We should avoid changing it,
> > but never ever changing it again in a backward compatible way seems to
> > me to be too constaining. We can make it easier to transition, though.
> > For example:
> > * announce in advance the change in format
> > * make change only for major release
> > * provide scripts to convert between formats
> > * document in the manual the range of compatibility
>
> That's all possible in principle, but seems unwarranted in this case.
Ok.
--
Pat
