> Date: Fri, 14 Aug 2026 16:42:32 +0200 > From: Patrice Dumas <[email protected]> > Cc: [email protected] > > On Fri, Aug 14, 2026 at 05:24:55PM +0300, Eli Zaretskii wrote: > > So it becomes impossible to control the encoding of the Info file by > > any specification in the Texinfo source? Why is that a good idea? > > > > I don't understand why the current situation, where we use > > @documentencoding, is a problem. > > 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. 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? > The second is about easing the implementation. We convert to UTF-8 upon > reading and do everything in this encoding, in particular determining > line width for cutting lines, or centering or flushing right. In Info > output, however, we also need to track the bytes count in the output > encoding to fill the Info tag tables that allows to find anchors and > nodes in Info file. Therefore, we do the output in two phases, first > conversion in UTF-8 and then encoding to determine bytes counts. In > some cases it is not easy to do it in two phases, we need to convert > back already encoded strings to UTF-8 to do the counting. Outputting > in UTF-8 only would remove > * the need to do two phases > * the need to convert back > > > 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. But since I'm not a Texinfo developer, you can feel free to disregard my opinions.
