zellij: Zellij won't read config changes to locked mode

Right. @a-kenji - I understand you not wanting to have Zellij open similarly named files by default or throw an error because they exist. I get it. That’ll for sure be bad UX.

While I think the setup command is really cool - it definitely is something you need to know about. No matter how prominent it is in the docs, if you’re looking for something else you are very likely to glance over it. Even if it’s literally one line above the thing you were looking for. That’s how we as devs browse documentation - there’s no avoiding that. 😃

What do you think - since this is a hot-button issue - that we look just at this one case and try to solve it?

IMO, the main issue here is the “yml” vs. “yaml” endings. Both of which are acceptable and common endings. Here’s an example of how “docker-compose” solves it:

$ ls | grep docker-compose
docker-compose.yaml
docker-compose.yml

$ docker-compose up -d
WARNING: Found multiple config files with supported names: docker-compose.yml, docker-compose.yaml
WARNING: Using docker-compose.yml

For our case, this might be a little problematic because Zellij clears the terminal as soon as it starts. We could build a warning infrastructure that would sleep for a few seconds while displaying warnings (if they are there) and then start the app. But this seems like a lot of work for just one instance that we don’t know if will be the first of many or not.

How about we throw an error just for this case of yml vs. yaml? No Levenstein distance or anything. There will not be a slippery slope here. Just this one. Instead of supporting both like other tools (or at least like docker-compose), we’ll just have this behaviour that will save users from this case? Clearly, users who don’t know about setup hit this. Two maintainers hit this - one of whom did know about setup but wasn’t thinking of using it (honestly, it was so obvious to me that the problem is elsewhere that I didn’t even think of trying - us Humans are fallible and sometimes need to be spoon-fed… or at least I am 😃 )

Do you think we can accept both suffixes?

@imsnif We could, but I think this idea has very little merit and just adds complexity and potentially confusion.

To quote from the documentation:

By default Zellij will look for config.yaml in the config directory.

We already support multiple config directories, in order to make it easier for the user as well as to comply with platform specific directories, as well as make it possible for distributions to use their system directories for further customization:

1. $HOME/.config/zellij
2. default config location (they differ on darwin and linux)
3. system location (/etc/zellij), can be configured by a compile time flag by distributions

In that order.

That means we look for example for config files on linux in this order (excluding env vars and config options):

1. $HOME/.config/zellij/config.yaml
2. (same as above on linux)
3. /etc/zellij/config.yaml

We already tell the user very clearly where the correct location is and even which location currently is loaded, try it out yourself:

mv ~/.config/zellij/ ~/.config/zellij-bak
zellij setup --check
mkdir ~/.config/zellij
zellij setup --check
zellij setup --dump-config > ~/.config/zellij/config.yaml
zellij setup --check

If we now add and ambiguous name for config files we now need to look at twice the amount of locations, the config files need to have an order. Which one has precedence? I think we are already flexible enough in supporting multiple directories. This could lead to problems in people sharing configurations. This is all implicit behaviour and I would like it to be as clear as possible.

So I would like to keep the name of the config file that we are loading to a single file, which name that is I don’t really care. But I don’t think multiple are a good way to go.

Also if we can avoid fixing it for now and let some hacktoberfest people get involved it would be awesome 😃