Clarify difference between \problemname and \problemname{}

[niemela]

If I understand LaTeX correctly, (and our spec), \problemname should mean "Insert problem name here", and \problemname{} should mean "set name to empty string (and insert it here)".

Do we want that? An empty name should be an error anyway? Would it be better is \problemname{} was specified to mean \problemname or to be an error?

[RagnarGrootKoerkamp]

Some editors warn on stuff like some sentece with a \command blah blah, encouraging to write \command{} instead. So probably we should make \problemname{} and \problemname equivalent to both use the name given in the yaml.

[thorehusfeldt]

I also expect \foo and \foo{} to behave the same in LaTeX.

In fact, my favourite definition would be this:

1. If \problemname does not appear in the statement source then the title in inferred from problem.yaml.name.
2. If \problemname does appear in the statement source then the title is the argument of \problemname. In particular, \problemname{H$_2$O} makes sense (the title is “H₂O”), and so does \problemname1(the title is “1”, that’s just how LaTeX rolls) and \problename{} (the title is explicitly empty).
3. I expect the tool to complain about \problemname followed by \s or \n or other whitespace.

[niemela]

@thorehusfeldt If

I also expect \foo and \foo{} to behave the same in LaTeX.

and

\problename{} (the title is explicitly empty)

Does that mean that \problename also sets the title to the empty string? (I think that's implied?)

Then why:

I expect the tool to complain about \problemname followed by \s or \n or other whitespace.

?

Also, should we allow an empty title? Why?

[thorehusfeldt]

Does that mean that \problename also sets the title to the empty string? (I think that's implied?)

That would be the consequence of viewing \problemname as the same as \problemname{}.

Since the semantics is unclear, I would expect a tool (such as verifyproblem) to complain about a bare occurrence of \problemname in statement.*.tex, for instance by emitting a warning.

The user either meant “Just put the problemname from problem.yaml:name at the top of this page” (in which case the user should omit the \problemname macro entirely), or the user meant “I want an empty title on this page” in which case the user should be incentivised to explicitly write \problemname{}.)

[RagnarGrootKoerkamp]

Can this 'complete lack of \problemname implies the yaml one' be implemented nicely purely in latex?

Currently we pretty much require \problemname to be present, and this is nice because we can just render either the given argument or fall back to the yaml one.

With the new suggestion, if there is no \problemname, we will either have to inject it from python, or do some latex magic where we render the statement.tex, then detect if \problemname was called, and then go back and fix things in a second pass or so? I'm sure it's possible somehow but probably not cleanly.

[thorehusfeldt]

Can this 'complete lack of \problemname implies the yaml one' be implemented nicely purely in latex?

Hm… I am no longer the LaTeX expert I once was, but my honest answer is “not sure”. I no longer know what to think about this and retract any claim I ever made about this issue.

Since overriding the problem.name is seldom, I wouldn’t find it insane to ask authors to do it explicitly:

\renewcommand{\problemyamlname}{H$_2$O}
\problemname

This adds no overhead to the specification and leaves LaTeX shenanigans to be solved with established LaTeX solutions. But since there are now also .md statements, I have no idea how to even think about this.

[RagnarGrootKoerkamp]

This last suggestion SGTM. So we require that \problemname is present, and allow overriding of \problemyamlname.

@niemela does that work with the way kattis/problemtools builds the statements?

[niemela]

Can this 'complete lack of \problemname implies the yaml one' be implemented nicely purely in latex?

Currently we pretty much require \problemname to be present, and this is nice because we can just render either the given argument or fall back to the yaml one.

That's a very good point. I.e. if it can't be implemented nicely in LaTeX, maybe we should require it to always be present? (if the title should be rendered, I guess?)

Since overriding the problem.name is seldom, I wouldn’t find it insane to ask authors to do it explicitly:

Agreed, but isn't \problemname{<name>} exactly that?

[niemela]

This last suggestion SGTM. So we require that \problemname is present, and allow overriding of \problemyamlname.

@niemela does that work with the way kattis/problemtools builds the statements?

I don't see why it wouldn't work.

But I really don't see the benefit of (re-)introducing \problemyamlname. Requiring \problemname seems fine (I would maybe even argue that there is a pedagogical value in always having it there), and if you want to specify a LaTeX version of the name (i.e. H$_2$O instead of H2O, then you can do so using the argument of problemname, like so: \problemname{$_2$O}).

My original question was about the difference between \problemname and \problemname{}. I feel that I got somewhat contradictory answers, but if I squint a but I can choose to interpret them as: \problemname and \problemname{} means the same thing, namely "insert problem name here" \problemname{<some value>} means "insert <some value> as the problem name here" with the assumption that <some value> is a the LaTeX version of the problem name specified in problem.yaml.

This sounds good to me.

...

...but to dig even further into the weeds. Maybe we shouldn't require \problemname, but rather say that this where the name is put... so if you don't include it, it is not included at all? What I'm saying is that this doesn't have to be an error, it could be a warning (or nothing)... But I might be overthinking it now?

[RagnarGrootKoerkamp]

Ah! So that brings us back to my suggestion at the start here (#350 (comment)).
I'd then say:

• \problemname is required. Ideally before any output is printed (but after a \newcommand is fine). I think tooling should be able to rely on this for incrementing the section label from A to B and such.
• \problemname and \problemname{} use the name in the yaml.
• \problemname{...} uses the given name instead.

And indeed, \problemyamlname is not in the spec (and only a bapctools implementation detail).

[niemela]

Ah! So that brings us back to my suggestion at the start here (#350 (comment)).

Indeed. :)

[Tagl]

What I'm saying is that this doesn't have to be an error, it could be a warning (or nothing)...

If it is a warning, how can I get rid of the warning?
In an ideal world, I am somehow able to get rid of all warnings by explicitly saying "No, this is really what I want!"

[niemela]

If it is a warning, how can I get rid of the warning?

That seems outside the scope of the spec to me? I.e. that's an implementation detail of any system using the spec.

In an ideal world, I am somehow able to get rid of all warnings by explicitly saying "No, this is really what I want!"

Agreed.