trim whitespace in loading LaTeX classes and packages

[dginev]

Minimal example:

\documentclass[
	aps, pra]{revtex4-2}
\begin{document}
Hello world.
\end{document}

This leading \par in the options of \documentclass was the first encountered problem in a recent arXiv report, which turned out to be also related to a greek babel regression, reported in #2429 .

I took the opportunity to sanitize (by trimming whitespace) the options argument to \documentclass, \documentstyle, \usepackage, \RequirePackage, \LoadClass, \PassOptionsToPackage, \PassOptionsToClass, \ExecuteOptions.

This may be removed soon after in a world where we load all of latex.ltx raw, but I realized that only after completing the code changes. So filing the PR in any case, for your consideration.

[brucemiller]

This kinda screams for either a Trimmed type of argument, or at least that the option processing routines would trim their arguments.

[dginev]

Done, thanks. I tried a couple of approaches, then realized the argument handling happens at different stages - some options are Tokens, others are already Boxes (typically a List). So doing the sanitization after the string phase is easier in the short run.

Parameter types could improve too, but OptionalTrimmedSemiverbatim seemed to be a mouthful.

[dginev]

I also found 5 places in 5 bindings which can benefit from sharing this new helper function. I haven't committed them here yet, let me know if you'd like them added (in authblk, cleveref, elsarticle, enumitem and ntheorem).

[brucemiller]

Hmm (again). So actually all(?) of these are cases of keyval or option lists, but at a somewhat special top-level, which may not be quite the same as the usual keyval processing. And a 3rd hmm is that these are commands that call for special treatment anyway, so are likely to always need LaTeXML bindings even if we read latex.ltx. I wonder if some use or adaptation of OptionalKeyVals would be the best long-term approach?

[dginev]

The parameter type name that resonates with me is PackageOptions, since the comma list convention is a top-level latex convention for classes and packages.

With that name we could even avoid the leading Optional, since they are always optional.

I am also wondering if we should be comparing to DirectoryList and CommaList here, rather than KeyVals.

[brucemiller]

Options aren't always optional, conceivably. Think of something like the various \setkeys commands that are out there. And I believe some packages accept keyval options, and probably more will in the future; possibly even \documentclass ? So, I'd think keyval is still the right basis, to the extent we can keep things compatible across all the use cases.

Of course, there are subtle differences between the implementation packages and appropriateness for \usepackage. See
https://tex.stackexchange.com/questions/26771/a-big-list-of-every-keyval-package

[dginev]

Ok, but aren't these key-val related considerations out of scope for this PR? Currently we treat "package options" as comma-separated lists, which is an expectation that goes all the way down into InputDefinitions.

I fear switching to a KeyVals object will have to propagate some large refactor all the way into Package.pm, while this PR just wanted to land a bug fix for whitespace handling.

Creating a new parameter type is fine by me, which can be refactored later as needed. But I don't think it is realistic to do much more than that before v0.8.9 is out.