On Fri, Aug 14, 2026 at 08:54:49AM -0700, Per Bothner wrote:
> On 8/14/26 07:54, Eli Zaretskii wrote:
> > I understand why supporting only UTF-8 is easier. What I don't
> > understand is how will we justify the removal of a useful feature just
> > because it's harder to support.
>
> I don't understand why handling non-UTF-8 info files a useful feature.
It's obviously useful to handle them because ssuch files exist and users
want to be able to read them. The question is about whether texi2any should
continue to have the facility to create such files.
> Note that info is a *binary* file format, it is not technically a text file
> format.
> Info files are meant to be read by a specialized info-reading application,
> not a generic editor or file viewer, unless that application has specific
> info support.
> As such, support for non-UTF-8 encodings in the strings contained in an info
> file
> is a useless complication.
>
> (As I've said many times, the info file format should be phased out and
> replaced by html.)
The current state of ideas on this is in TODO.HTML in the Texinfo sources.
My main idea for the next thing to work on was one of documenting details of
the HTML output of texi2any, but I just haven't got to this yet:
A possible first step is to encourage installation of Texinfo-derived
HTML documentation and add support to whatever programs people use
to read locally-installed documentation on their systems. (Better
support for indices and search paths could be added later.)
So that these Info features could be added later, installed HTML
manuals should be installed in standardised locations and contain
needed information. There should be some degree of stability in
the HTML produced by texi2any to allow such features and the Texinfo
project should agree and document what this stability entails (e.g.
inter-manual links, identifying index nodes).
