Configuration files for luaotfload

[zauguin]

Looking into #200 I looked over the configuration file loading if luaotfload which reminded me that it is kind of a mess: Currently the first of the following files is loaded:

• ./luaotfload.conf
• ./luaotfloadrc
• $XDG_CONFIG_HOME/luaotfload.conf
• $XDG_CONFIG_HOME/luaotfloadrc
• $HOME/.luaotfloadrc
• Kpathsea lookup for luaotfloadrc
• Kpathsea lookup for luaotfload.conf

There are quite some issues I have with this:

1. Why is sometimes luaotfload.conf preferred and sometimes luaotfloadrc?
2. Why do we need two names in the first place? Especially for the potentially costly kpathsea lookup this seems like a waste.
3. Why should the user configuration file (e.g. in $XDG_CONFIG_HOME/luaotfload.conf be skipped if ./luaotfload.conf is present?

One suggestion to improve this would be:

• Only use luaotfload.conf, but additionally look for luaotfloadrc for now and throw an error if it exists to avoid silently breaking something.
• Load all found files in reverse order of preference. (So that local files can overwrite settings from more global files, but settings which are not overwritten still get applied.)
• Remove the config.actions interfaces in the process or at least move them into less generic names.

Of course, this is potentially breaking existing configurations, but I would assume that these aren't used that much in the first place and even if people use these files, they can just rename them.

[vlasakm]

Considering that this is for user configuration files only (disregarding our discussion in #200):

* Only use `luaotfload.conf`, but additionally look for `luaotfloadrc` for now and throw an error if it exists to avoid silently breaking something.

Agreed.

* Load all found files in reverse order of preference. (So that local files can overwrite settings from more global files, but settings which are not overwritten still get applied.)

Nice, this would allow useful interaction between project specific and user specific configurations.

Is the Kpathsea search even desirable at all for user / project specific config files?

[vlasakm]

Also: maybe there still would be a reason for allowing configuration through Lua code. This would allow embedding the config in the project itself, instead of having to rely on potentially missing config file.

Maybe even adding an option to disable loading any external configuration files, to ensure document that document compiles the same in setups of different people.

[zauguin]

Considering that this is for user configuration files only (disregarding our discussion in #200):

I haven't completely given up on using this more generally yet, but for now that's look into the user use case.

Is the Kpathsea search even desirable at all for user / project specific config files?

I think it is, mostly because it's just something I would expect as a TeX user (Actually I keep forgetting that $XDG_CONFIG_HOME and would probably store my personal config in ~/.texlive2021/texmf-config/... or ~/texmf/... or something instead) and because especially for documents in bigger projects, multiple documents in different directories might share a configuration, which is much easier when the search path can be influenced.

Also: maybe there still would be a reason for allowing configuration through Lua code. This would allow embedding the config in the project itself, instead of having to rely on potentially missing config file.

Maybe even adding an option to disable loading any external configuration files, to ensure document that document compiles the same in setups of different people.

Most project code actually runs after luaotfload is loaded, so the available range of options there is somewhat limited. Of course there is support for changing the options for which it makes sense, but it's a mess and should get a cleaner interface and more appropriate names.

I'm not too happy about disabling configuration files completely because we have too many settings which assume to have consistent values system wide. If someone really wants to fixate everything, they can always set all options, but especially for the options affecting the database I want it to be an explicit decision to go over the users wishes.