On Fri, Aug 14, 2026 at 05:54:17PM +0300, Eli Zaretskii wrote: > > Date: Fri, 14 Aug 2026 16:42:32 +0200 > > From: Patrice Dumas <[email protected]> > > Cc: [email protected] > > > > The first issue is about the encoding of cross-references. With a mix > > of encodings, the cross-references in the source and target manual may > > not match. The Info readers could mitigate this issue, but it would > > involve more decoding/recoding. For the C Info reader, Gavin decided > > that it is not worth it (it is documented in the manual). > > Emacs decodes each file it reads separately, and if that file > specifies its encoding (as it should be in case of Info file), this is > even 100% reliable.
The standalone Info reader does that too, to present the Info in the needed locale. But it is not sufficient for cross-references, though I do not remember why. > It is okay for the stand-alone Info to only support UTF-8 encoded > manuals, or not support cross-references to a manual that is encoded > differently, but why should this decision affect what makeinfo does? It is not the only reason, but it is an additional reason. > > More generally, having only UTF-8 encoded Info manuals will only > > simplify things in the long term, without any drawback. Info files are > > not usually manually modified, people modifying Info files manually > > will know what to do about encodings. > > 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. The point is that this feature is not really useful, because Info readers should always render correctly UTF-8, other encodings are not needed. I can't imagine a case where a user would want an Info file in a specific encoding. It could be different if Info files were supposed to be edited, but it is very rare. In a way the Info files should be considered as a kind of binary files that are only to be processed by tools that know about the format. -- Pat
