driver (library) chatter referring to the tectonic binary command line options

[ratmice]

trafficstars

I had been using the latex_to_pdf functionality. On first run of the program when it downloads styles and sets up the tectonic cache it takes quite a long time, with no feedback because it's using the chatter level status::NoopStatusBackend::new, and has print_stdout to false.

As such I had started moving towards setting up the engine manually, And used the chatter level of Normal, The output of such refers to arguments my program doesn't currently accept. I.e. src/driver.rs refers to arguments accepted by src/bin/tectonic.rs

It isn't hard to add these to my program, and I shall, but it is worrying if e.g. bin/tectonic adds some new option, driver starts referring to that, and in an update I don't notice so my program starts recommending options it may not recognize.

• --keep-intermediates
• --print/--keep-logs ditto ditto finally

I'm not exactly sure I have any good ideas for a good solution, three came to mind

1. Having a specific chatter level for the tectonic binary.
2. A fancy enum callback/formatting scheme.
3. A mechanism my program can use to direct tectonic options directly to the driver.

1 I'm not sure is plausible, as we see some of the chatter are warnings rather than just notes. 2 Seems overkill, especially when we see various similar messages worded slightly differently based upon context, It looks like the most painful option. 3 seems like it could work and be future compatible and least hassle.

I am reminded of the MLWorks compiler driver which worked like 3. The compiler driver would essentially ignore options hat weren't wrapped in a begin/end marker such as: foo --begin-tectonic --print --keep-intermediates --end-tectonic the foo program would then forward options wrapped between begin and end marker to the driver which included option parsing (moving some option parsing from src/bin/tectonic.rs to src/driver.rs presumably).

I'm curious if anyone has any opinions on any of these or alternate solutions.

[pkgw]

Ah, this is an interesting and subtle issue! I hadn't thought about this aspect of the user interface messages.

I have been interested in the idea of moving many aspects of the option parsing to src/driver.rs anyway, since I like the idea of using structopt precisely to make it more tractable for users of the "driver" functionality to control its options in a more reliable way. This was motivated in part by #175, where I'd like to expose ways to control the engine that are a bit more specialized than the basic tools that we currently present. I like the idea of rustc/cargo-like -Z options to give users helpful features without really committing a CLI interface that will accumulate zillions of bells and whistles.

Anyway, such a change would help in this area, but I don't think it would fully resolve the issue. At the moment, my intuition is saying that most thorough solution would be something like your option 2. Maybe add some kind of callback to the StatusBackend trait called, I don't know, engine_control_message() with an enumeration of specific things that have happened in the engine that might have turned out differently if it was configured differently: e.g., IntermediateFilesDiscarded. The CLI implementation would turn that into a message about using --keep-intermediates, but some kind of GUI might turn it into a message about "Click the "Keep intermediates" checkbox in the configuration window".

But I definitely agree that this is a tricky issue and I don't see a single obvious best approach! @Mrmaxmeier I would be interested in any thoughts you might have.