The problem of local configurations

[ayham-1]

Currently, any receive commands asks for directory and/or name of file.

This is not really useful when you are solving problems, and can be really annoying after some time.

The issue is, a configuration option can't be used as the configuration needs to be local and extended (this is how it is currently with config.load_local_config_and_extend).

Also, if a new problem is downloaded from a problem-set, it won't have a specific local configuration, as the problem does not exist on system for it to have a local configuration.

And if a per judge configuration is required, this should be done in the main configuration, as per judge configuration is not local to the problem but rather specific to the judge (by definition).

And specific compiler commands should have another solution than having local config files per problem, maybe a keybinding.

I think dropping the local configuration would allow the project to have configuration options, like "contest_directory", which would enable functionality similar to how cpbooster.nvim works.

If this is fine with the maintainer @xeluxee, I would like to work on such functionality.

[ayham-1]

After further inspection, it appears that there is a way to access the configuration options before loading the local configuration.

However, a predetermined path choosing for problem/contest destination still means a difference in how local .configurations.lua files are done.

[xeluxee]

The issue is, a configuration option can't be used as the configuration needs to be local and extended (this is how it is currently with config.load_local_config_and_extend). Also, if a new problem is downloaded from a problem-set, it won't have a specific local configuration, as the problem does not exist on system for it to have a local configuration.

No, when you download a problem the local configuration is loaded from the directory you choose

And if a per judge configuration is required, this should be done in the main configuration, as per judge configuration is not local to the problem but rather specific to the judge (by definition).

What settings would you like to change for different judges?

I think dropping the local configuration would allow the project to have configuration options, like "contest_directory", which would enable functionality similar to how cpbooster.nvim works.

Local configuration is often useful, so I won't drop it until we find a better system. You can use global options like contest_directory anyway, because local configurations can be simply ignored when looking for that option.

After further inspection, it appears that there is a way to access the configuration options before loading the local configuration.

You can ignore local configurations using global setup options: require("competitest.config").current_setup.<option name>

However, a predetermined path choosing for problem/contest destination still means a difference in how local .configurations.lua files are done.

So you'd like to store all contests in a predetermined folder configured with setup()?

[ayham-1]

So you'd like to store all contests in a predetermined folder configured with setup()?

Yes, I figured it would be better to offer a boolean configuration which switches between predetermined paths and prompting the user.

About the judge, it was just a point addressing local configuration, however, now I think a switch system configured from setup() is a better path.

[neov5]

Reviving a dead thread, but this is an issue while receiving problems. The way the readme is phrased makes it look like .competitest.lua is loaded whenever the plugin starts up, but it's used only when reading contests. This causes receiving problems to default to the original config.

For example, if I have two templates:

default_template.cpp
judge1
`- .competitest.lua
`- judge_template.cpp

My original config uses default_template.cpp while .competitest.lua uses judge_template.cpp. Problems received in the judge1 directory use default_template.cpp, but contests received use judge_template.cpp

Either the readme should be fixed to clarify this, or the code should be updated to load the local directory config on init (I've done so in a fork, happy to send a PR if required)

[seraph27]

@neov5 I also had the same confusion until I saw this thread. I think it would make more sense if every folder in the subfolder is affected by .competitest.lua regardless of fetching problems or contest.

Since I have templates separately for codeforces / atcoder and every judge, and I can't figure out a way to use separate templates when running "CompetiTest receive problem"

[seraph27]

nvm, I just copied that one line from your fork and it works but maybe the maintainer want to reword the readme if its intended

[xeluxee]

This causes receiving problems to default to the original config.

Fixed with 20ce9ba1b2f7502291a23ad06096e6650917f0c2.