> From: Gavin Smith <[email protected]> > Date: Mon, 14 Sep 2026 20:47:50 +0100 > Cc: Patrice Dumas <[email protected]>, [email protected] > > > In general, removing features that were supported for a long time is > > IMO harsh and should be rarely if ever done. But that's me. > > If I understand correctly, the functionality still would exist, and > be provided by OUTPUT_ENCODING_NAME.
One problem with that option is that it was added only very recently, so you cannot use it in a Makefile unless you force the use of a very recent Texinfo. Emacs, for example, supports old versions of Texinfo all the way down to 4.12. > > More generally, you asked for opinions, and I provided one. I hope > > it's helpful in some way. > > I don't fully understand your use case for non-UTF-8 encoded Info > files The use case is a Texinfo source encoded in some encoding that cannot be easily converted to UTF-8. Another use case is when for some reason the preferred output encoding is not UTF-8. > but it does appear to exist and it appears to be easy to > continue the current behaviour of letting the input encoding determine > the output encoding, so I think we should not change the behaviour. That would be fine by me. > Patrice's question was to discover if users depended on or preferred > the current behaviour and from your experience this appears to be > the case, so this is a strong argument for not changing it. > > It does appear to me that this use case would entail the author of the > Texinfo files also being the reader of the Info files, as they are produced > and consumed in a similar locale environment. Usually, they would be > independent: e.g. just because a Texinfo manual was written in a Latin-1 > locale, doesn't mean that the user is reading it in a Latin-1 locale. That's true, but it could well be that a Texinfo manual is written to target a specific locale, for example if it is a translation of the manual to some specific language whose users prefer non-UTF-8 encoding.
