CLI: treat variables with value true or false as boolean

[tarleb]

Variables with boolean-looking values are now converted to booleans when
defined via the command line. This matches the existing behavior for
metadata values.

Closes: #10340

[jgm]

I'm trying to remember whether there was a reason for not doing this. Here is one possible reason: if a user wants a variable to be the literal string "true", this change would make that impossible.

Note that in a defaults file, you already can give variables boolean values (I think). But the YAML format there makes it possible to distinguish between "true" and true. On the command line we don't have anything like that.

I suppose it's a limitation of the current behavior that one can't give a variable a false value on the command line. But not giving it a value has the same effect in conditionals.

[tarleb]

Being able to give a boolean value of false could be useful to override the same value in the metadata, but I admit that it's not a particularly likely scenario.

One approach that should prevent rendering changes would be to simply check for the two strings true and false, because that's what boolean variables are rendered as. But that would still leave the issue that metadata and variables are parsed differently.

[jgm]

I suppose this issue is also related to #10298. One could imagine a special syntax that says: interpret this variable value as JSON.

[iandol]

Being able to give a boolean value of false could be useful to override the same value in the metadata, but I admit that it's not a particularly likely scenario.

In fact this is really really useful IMO. I often have a defaults file or other metadata for general use, but then I want to quickly override the defaults for a one-off document. See

#10301

for some examples, e.g. I usually set colorlinks to true, but occasionally want to override this. At present I have to keep making new defaults files for each possible permutation of metadata state as command-line values cannot override them.

I wonder if we can have some other workaround to set either a string or a boolean, how about @ to identify a string: pandoc -M colorlinks=@true -t native?

[tarleb]

We could allow types to be specified with /type, e.g. -V colorlinks/bool:true. This wouldn't interfere with any current syntax, is reminiscent of template "pipes", and would allow to also solve #10298 with -V 'complexvar/json:{ "this is json": true}'.

[jgm]

Well, if we had /json, we wouldn't need /bool, because false is a perfectly good JSON value.

[tarleb]

An explicit /bool type might still be useful for an input like FALSE, which would be accepted as boolean metadata, but isn't valid JSON.

[jgm]

I was just thinking that have one "special" marking might allow us to simplify notation, e.g. --variable foo=@false or --variable baz='@{"foo": "Bar"}'.

[jgm]

I guess the special marking could go either on in any of three places, so we'd need to think about that:

• --variable/json foo=false
• --variable foo/json=false
• --variable foo=json/false

[alerque]

The first of those makes way more sense to me and I dare say would be a lot easier to cope with generating commands programmatically (something I do a lot of): --variable/json foo=false.