On Sat, Jan 18, 2025 at 09:59:38PM +0000, Gavin Smith wrote: > On Sat, Jan 18, 2025 at 03:27:05PM +0100, Patrice Dumas wrote: > > Hello, > > > > I propose to use the following syntax using glob for files to be found > > in a directory relative to the htmlxref.conf where the htmlxrefinclude > > directive would be found: > > > > htmlxrefinclude dir/*.conf > > > > What do you think? > > A different approach could be not to use an include or import directive > at all, but to use a directory "datadir/texinfo/htmlxref.d", all files > within being searched. This could be simpler. I don't see much of a > need for a top-level htmlxref.cnf file referencing htmlxref.d.
I agree, but in some locations an htmlxref.cnf file could be better, for instance in the current directory, in the Texinfo file directory, in XDG_CONFIG_HOME/texinfo and ~/.config/texinfo/. > In case of conflicting data for a manual, all I can think of doing is > issuing a warning in case that manual is referenced. I think that it is an independent issue than the issue at hand, as it may happen with htmlxref.cnf files only too. > In case of both datadir/htmlxref.cnf and datadir/htmlxref.d being > present, we could read both. That could be the simplest possibility. We could even do that for every possible location without special case for current directory, the Texinfo file directory, or directories in HOME, but we would document that it may not be such a good idea to use a directory in these cases and that htmlxref.d is more relevant in datadir and sysconfdir. > There's also the question of whether to use datadir (/usr/share) or > sysconfdir (/etc). You wrote: > > > To me data vs configuration is, in general, not about the nature of the > > information, but about the intent on how a resource is modifiable and by > > whom. If the resource is considered to be a non-changeable asset, it is > > data, but the exact same file could be configuration in another place > > where it is editable. It is the established practice, in sysconfdir the > > installed or searched files are supposed to be edited, while the files > > installed in datadir are not supposed to be edited, and could be mounted > > read-only. The XDG Base Directory Specification allows this > > interpretation by not defining precisely what data and configuration is. > (bug-texinfo, 2024-08-29) > > In that case, they are "data" as they would be overwritten by software > installations and upgrades and so shouldn't be modified by users. In datadir only, to me in sysconfdir this is supposed to be modified by users. And if there are files added in datadir/texinfo/htmlxref.d by users, they could be left as is. But I do not see the issue here. > If we did use an "include" directive, then one problem is that a word > at the beginning of the line may be misread as a name of a manual, > so a prefix at beginning of the line like "@" would be good to have. > For example, CSS uses "@import". I do not think that it is a real issue, and your idea is good, it could be @htmlxrefinclude, but even htmlxrefinclude could never have been a real manual name. > Backwards compatibility is another reason not to add an include directive > to htmlxref.cnf, although this would only be in an ununusal setup, like > making htmlxref.cnf a symlink in some of the Texinfo installation directories. I do not think that backwards compatibility is so important here, to me it is more important to have the best setup. In any case, I said above, my preference now would be to use both an htmlxref.cnf and files in htmlxref.d/*.cnf in all the directories where htmlxref.cnf are searched for currently and no include directive. -- Pat
