Wire in support for -Z options

[pkgw]

Now that we have structopt (#465), the next thing I'd like to do is add support for -Z options as used by programs like rustc and cargo. The basic idea is to give us a way to let people activate unusual engine features, like shell-escape (#38) or min-crossrefs (#175), without proliferating an endless series of long command-line options:

tectonic -Z bibtex-min-crossrefs=1000

In particular, I think that Rust folks have gotten a sense that -Z conveys that features are unstable and might go away. I certainly don't expect us to have a nice stable/unstable split any time soon but we might eventually get there.

The last time I looked at this, I got stuck since it was going to take a little bit of effort to figure out how to get the CLI frontend to control the backend driver, but fundamentally there shouldn't be anything too complicated here.

[ralismark]

I've been experimenting with this (among other things) on the experiments branch of my fork. My current setup is to have an UnstableOptions struct which gets passed to the various engines in src/engines/. The individual engines then interpret the relevant options from the struct.

My current method of parsing -Z arguments is to prepend -- to each value and parse it into UnstableOptions using structopt (see here). It works, but the error messages produces are very unhelpful - do you know of a cleaner way to parse these options that still has decent error messages?

[ratmice]

My inclination when looking at the change here is whether this could use the possible_values instead of going from Vec<String>, using that to go directly to UnstableOpts in the top-level struct.

Perhaps theres a reason that doesn't work though?

[ralismark]

Some options take a value e.g. -Z bibtex-min-crossrefs=1000 so I don't think we can use possible_values. I suppose a custom string parser could be used, but that doesn't address the error message issue.

[pkgw]

Yeah, I think it will probably hurt more than it helps to use structopt to parse the UnstableOptions contents. If I were doing this, I guess I'd try defining an UnstableOption enum:

enum UnstableOption {
    PaperSize(String),
    ShellEscapeEnabled,
}

then impl a FromStr for it that basically works like:

• papersize=letter => UnstableOption::PaperSize("letter")
• shell-escapes => UnstableOption::ShellEscapeEnabled
• none of the above => error value

And then have zero or more -Z flags parse into zero or more UnstableOption values. I don't know exactly how structopt deals with errors on custom string parsers, but I would think that it should allow for relatively user-friendly output.

Finally, there would need to be some kind of glue code that applies those UnstableOption values onto what you've currently got as the UnstableOptions struct, or perhaps that could just be skipped and they could be applied onto a general configuration struct.

Of course, I haven't tried implementing this, so no guarantees that this is the best way to go ...

[ralismark]

I've pushed a commit to experiments which uses this method - and yeah, it's definitely cleaner this way.

[pkgw]

@ralismark Cool! Is this work something that could be introduced in its own pull request?