> Date: Thu, 24 Sep 2026 23:06:49 +0200 > From: Patrice Dumas <[email protected]> > Cc: [email protected], [email protected] > > On Thu, Sep 24, 2026 at 08:49:48AM +0300, Eli Zaretskii wrote: > > > In my opinion, it would be better if a directory component in > > > @setfilename was ignored. In my opinion, it would be ideal if > > > @setfilename was ignored unless the Texinfo file is read from standard > > > input. We have to maintain backward compatibility, but I would be in > > > favor of deprecating @setfilename except for that specific use. > > > > Once again, such backward-incompatible changes should IMO and IME have > > very good reasons. What are those reasons in this case? Just the > > fact that this behavior might be surprising when you first hear about > > it? > > Nowadays, @setfilename should only be used to specify the basefile name, > and should not contain paths. It also should be the same as the input > file name (with .texi replaced by .info). It is therefore redundant > with using the file name if there is one. Therefore it could easily be > deprecated (except maybe for the case of Texinfo manual passed in > standard input), removing useless complexity in the Texinfo language. > > Note that this deprecation does not mean that we should stop immediately > supporting @setfilename. It only means that we should not document any > other use for newer Texinfo versions.
As long as you deprecate some feature but don't remove it, I'm okay with that. My interpretation of this discussion was that you are planning to make changes that aren't just deprecations, but disallow something that was supported until now. If that's not the case, I apologize for the noise. But if I was right, and changes are planned that will disallow what was possible before, then what people _should_ do nowadays is IMO not a satisfactory justification for such a removal. Of course, it's eventually your call. > Again it does not say anything about what we do for @setfilename nor > for @setfilename with path, we could still try to do something sane > and/or backward compatible to still support correctly manuals that > use the deprecated feature. IME, one should also consider what the current implementation actually does, not just what the documentation says.
