Store account, lang, ref in file modeline or dir-local .wbij.zon

maleszka commented

2026-03-22 22:16:10 +01:00

Owner

I think it would be nice to store account, lang, and ref inside submitted files after successful submit, so that the next wbij main.cpp doesn't even prompt for anything.

We can take an inspiration from Vim's modeline and store something like that inside files:

// wbij: lang=cpp20 ref=1341 account=test

Account might be either the user-provided id in config file or computed hash string that cache uses. During Config parsing stage, wbij would just search wbij: inside of the file (the same way, as vim, read :help modeline).

After submit, wbij may ask a [M/d/n] query whether to store this (account,lang,ref) data in Modeline or dir-local .wbij.zon. How will we know what's the format of comments? I guess it can be hardcoded in CodeLang?

I think it would be nice to store account, lang, and ref inside submitted files after successful submit, so that the next `wbij main.cpp` doesn't even prompt for anything. We can take an inspiration from Vim's modeline and store something like that inside files: ```c++ // wbij: lang=cpp20 ref=1341 account=test ``` Account might be either the user-provided `id` in config file or computed hash string that cache uses. During Config parsing stage, wbij would just search ` wbij:` inside of the file (the same way, as vim, read `:help modeline`). After submit, wbij may ask a [M/d/n] query whether to store this (account,lang,ref) data in Modeline or dir-local `.wbij.zon`. How will we know what's the format of comments? I guess it can be hardcoded in CodeLang?

kbity commented

2026-03-26 11:07:10 +01:00

Collaborator

Willing to self-assign to this, just have a few technical questions/remarks.

Account might be either the user-provided id in config file or computed hash string that cache uses.

I suggest we avoid inserting "magic" values wherever possible, so as to be maximally friendly to the user (especially when injecting data into their files). Hence, we could use id and just check whether the profile exists.

wbij would just search wbij: inside of the file

How far would we want the search to go? There's a potential conflict with the modelines of different text editors, and from my trial-and-error attempts I've found that Neovim parses a modeline when it's within the last 5 lines of a file. Should we also adapt some hard cap for the search depth or just grep on the file's contents?

How will we know what's the format of comments? I guess it can be hardcoded in CodeLang?

Yeah I guess that would work, it sounds like a lot of work to support platforms with dozens of available languages (notably CF) but as a first attempt it's good enough IMO. Worst case scenario we can just swap it out for something better /shrug

Willing to self-assign to this, just have a few technical questions/remarks. > Account might be either the user-provided `id` in config file or computed hash string that cache uses. I suggest we avoid inserting "magic" values wherever possible, so as to be maximally friendly to the user (especially when injecting data into their files). Hence, we could use `id` and just check whether the profile exists. > wbij would just search ` wbij:` inside of the file How far would we want the search to go? There's a potential conflict with the modelines of different text editors, and from my trial-and-error attempts I've found that Neovim parses a modeline when it's within the last 5 lines of a file. Should we also adapt some hard cap for the search depth or just grep on the file's contents? > How will we know what's the format of comments? I guess it can be hardcoded in CodeLang? Yeah I guess that would work, it sounds like a lot of work to support platforms with dozens of available languages (notably CF) but as a first attempt it's good enough IMO. Worst case scenario we can just swap it out for something better /shrug

maleszka commented

2026-04-06 12:35:11 +02:00

Author

Owner

I suggest we avoid inserting "magic" values wherever possible, so as to be maximally friendly to the user (especially when injecting data into their files). Hence, we could use id and just check whether the profile exists.

Just for the context, account "hash string" (defined here) is something like sim:test_user@sim.13lo.pl, so quite readable. Other than that, good point and I think we should parse only account id here. It's superior from the user perspective and it's simpler to parse.

When it comes to user-friendliness, I'm think ref might be more of an issue. I had decided in the backend that refs should be detached from the web platform itself. ContestNode.Ref is much more "vertex number in a graph" than "reference to something on the remote" thingy. It makes logic much easier to treat everything as one graph instead of contest/round/roundentry separation as we had in sim-cli. Currently, ref is some 64bits that PlatformAPI generated to identify an entity in the contest graph.

That being said, due to the nature of how refs are specified, I don't think modeline is something that the user is meant to type-in "by hand". It will always be generated by the CLI.

Also I see a benefit that both .wbij.zon and modeline have the same contest_ref: ?ContestNode.Ref field, which basically means "narrow down fuzzy search's space to the given subtree", which usually boils down to a single leaf (round entry in sim-cli terms).

Considering the "internal nature" of data in modeline, should we strip it before submitting solution code (i.e. remove line containing wbij:)?

How far would we want the search to go?

nvim/vim have modelines setting which determine the number of first/last lines. They do that cause they allow opening files of arbitrary sizes (they are reading lines on the fly). In our case, submission code is buffered in memory and limited to 1MB, so it's safe to just scan the whole buffer. Do whatever you think is reasonable.

Willing to self-assign to this

Thank you for support, bro!

> I suggest we avoid inserting "magic" values wherever possible, so as to be maximally friendly to the user (especially when injecting data into their files). Hence, we could use id and just check whether the profile exists. Just for the context, account "hash string" (defined [here](https://repos.adamm.rocks/maleszka/wbij/src/commit/28b9e21207812e0070875ef84275d58a975fb060/src/api/platforms.zig#L41-L47)) is something like `sim:test_user@sim.13lo.pl`, so quite readable. Other than that, good point and I think we should parse only account `id` here. It's superior from the user perspective and it's simpler to parse. When it comes to user-friendliness, I'm think `ref` might be more of an issue. I had decided in the backend that refs should be detached from the web platform itself. `ContestNode.Ref` is much more "vertex number in a graph" than "reference to something on the remote" thingy. It makes logic much easier to treat everything as one graph instead of contest/round/roundentry separation as we had in sim-cli. Currently, ref is some 64bits that PlatformAPI generated to identify an entity in the contest graph. That being said, due to the nature of how refs are specified, I don't think modeline is something that the user is meant to type-in "by hand". It will always be generated by the CLI. Also I see a benefit that both `.wbij.zon` and modeline have the same `contest_ref: ?ContestNode.Ref` field, which basically means "narrow down fuzzy search's space to the given subtree", which usually boils down to a single leaf (round entry in sim-cli terms). Considering the "internal nature" of data in modeline, should we strip it before submitting solution code (i.e. remove line containing ` wbij: `)? > How far would we want the search to go? nvim/vim have `modelines` setting which determine the number of first/last lines. They do that cause they allow opening files of arbitrary sizes (they are reading lines on the fly). In our case, submission code is buffered in memory and limited to 1MB, so it's safe to just scan the whole buffer. Do whatever you think is reasonable. > Willing to self-assign to this Thank you for support, bro!

kbity was assigned by maleszka

2026-04-06 12:35:23 +02:00

kbity commented

2026-04-08 16:47:47 +02:00

Collaborator

Considering the "internal nature" of data in modeline, should we strip it before submitting solution code (i.e. remove line containing wbij:)?

Sure, why not. I can see a potential use-case wherein the user would like to keep the lang and user id in the file to skip some of the configuration when resuming work on another machine, but I reckon it's too niche to take care of right now.

> Considering the "internal nature" of data in modeline, should we strip it before submitting solution code (i.e. remove line containing `wbij:`)? Sure, why not. I can see a potential use-case wherein the user would like to keep the lang and user id in the file to skip some of the configuration when resuming work on another machine, but I reckon it's too niche to take care of right now.

maleszka commented

2026-04-08 18:34:29 +02:00

Author

Owner

use-case wherein the user would like to keep the lang and user id in the file to skip some of the configuration when resuming work on another machine, but I reckon it's too niche to take care of right now.

How often do you download your submits from sim? How often do you use sim as the storage for your solutions? I just have one folder with all my solutions and that's what I synchronize across devices.

> use-case wherein the user would like to keep the lang and user id in the file to skip some of the configuration when resuming work on another machine, but I reckon it's too niche to take care of right now. How often do you download your submits from sim? How often do you use sim as the storage for your solutions? I just have one folder with all my solutions and that's what I synchronize across devices.

kbity commented

2026-04-08 19:11:29 +02:00

Collaborator

How often do you download your submits from sim? How often do you use sim as the storage for your solutions? I just have one folder with all my solutions and that's what I synchronize across devices.

Eh, fair enough.

> How often do you download your submits from sim? How often do you use sim as the storage for your solutions? I just have one folder with all my solutions and that's what I synchronize across devices. Eh, fair enough.