On Sat, Jan 18, 2025 at 03:27:05PM +0100, Patrice Dumas wrote: > Hello, > > I think that it would be better if it was possible to specify a > directory to be searched for files in htmlxref.conf to get more entries. > This would allow > * to have diverse community maintaining the different files > * easier customization, by dropping a file in a directory instead of > changing a file that is a reference file done by upstream. > > 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 > > An absolute directory would also be possible: > > htmlxrefinclude /a/b/*.conf > > The files would be expanded by calling glob. > > > 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. This is an approach to consider, as include directives could lead to issues like cyclical references and files being referenced in multiple other files. You could easily record where a setting came in, without recording the chain(s) of includes that led to that setting. For htmlxref.cnf files it would be easy to save the location of the config file with the specification for a particular manual. The existence of that file in the .d configuration directory would be the sole reason for the use of that specification, making it easy for a user to fix bad entries, without worrying about what other files import that one. (In some software I've used (e.g. text editors) it's sometimes been a source of frustration knowing exactly where a configuration setting came from, leading to my preference for simple, transparent, declarative config files.) (I read that systemd had an ".include" directive in their config files, but this was deprecated in favour of a "drop-in" directory, with a name ending in ".d" (although couldn't easily find an explanation of why they made this change).) In case of conflicting data for a manual, all I can think of doing is issuing a warning in case that manual is referenced. In case of both datadir/htmlxref.cnf and datadir/htmlxref.d being present, we could read both. 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. 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". 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. > If this is accepted, I would propose that we install in datadir/texinfo, > an htmlxref.conf with content: > > htmlxrefinclude htmlxrefdir/*.conf > > and in datadir/texinfo/htmlxrefdir/ we would install two files, > > htmlxref_Texinfo_GNU.conf > > and > htmlxref_Texinfo_other.conf Splitting it like this seems like a good idea.
