@DavidCarlisle \fontsize{\dimexpr #1 * \fpeval{0.93/088}\relax}{#1} was working tuesday when I was updating some font packages. And then stopped working when I used a doc that loaded calc. Is there a preference on this one: \fontsize{\dim_use:N \l_tmpa_dim}{#1} or is \fontsize{\l_tmpa_dim}{#1} enough?
Anyone had the situation with an expl3 sty or cls where ~ no longer printed a space, but {~} does? Not sure what I did wrong. It is inside a \parbox if that is relevant.
Hmm, something else is going on here I currently have \_foo_get_kw:n {foo} \nobreakspace \_foo_get_kw:n {bar} which leaves no space but \_foo_get_kw:n {foo} \nobreakspace a \_foo_get_kw:n {bar} Does. I've probably forgotten something.
@daleif I tried the doc you posted above (with calc commented out) in texlive 2022/23/24 at overleaf and also locally and all gave same error ! Improper at' size (0.0pt), replaced by 10pt` I don't see any change in behaviour recently?
@DavidCarlisle For some reason the code did work for me on tuesday and not on wednesday? No idea why.
For some reason I'd like to auto generate macro setters from a clist of keywords/names. They setters may take an optional argument, do we then need to use something like \NewDocumentCommand{\csname set#1\endcsname}{om}{....}?
@UlrikeFischer not quite understod. I think I'll just go with \ExplSyntaxOff \input \ExplSyntaxOn for now
What exactly does this error mean: LaTeX Error: \RequirePackage or \LoadClass in Options Section? I'm playing with \DeclareKeys and \ProcessKeyOptions to be used as class options. The \RequirePackage comes after \ProcessKeyOptions as the load depends on the value of the class option.
@JosephWright I haven't even used \DeclareOption, only \DeclareKeys, and as I mentioned the error comes some lines after \ProcessKeyOptions (and is actually a switch statement). Perhaps there is some interaction with still loading xkeyval (I'm switching between the two to see if the behavior is correct).
@daleif the error shows on the next line as RequirePackage has a trailing optional argument and latex has looked ahead for that, so it is unrelated to the \providecommand, that's why you often see \RequirePackage{iftex} \relax to keep any error message reporting that line not the next
@daleif having \DeclareOption(X) between \DeclareKeys and \ProcessKeyOptions seems a bit brave, why interleave the two mechanisms in the same class, I'd handle the options with one or the other not try to use both for the same option list.
@DavidCarlisle because I'm converting from one to the other, not writing from scratch. In many cases it is useful to lave the old code just to double check. I think I'll just redefine \DeclareOptionX to eat its arg. I have to setup a lot of code before \ProcessKeyOption, including autogenerated class options.
@daleif no really not here. You can convert the class in stages, but handling the option list is an atomic operation (and tricky at the best of times) running the entire list through two competing option handlers will lead to pain even if you manage to find an order that avoids errors.
@daleif an undocumented one. Something like \keys_define:nn { daleif } { foo-internal .code:n = { <foo code> }, foo .meta:n = { foo-internal={#1}, bar } } and you only document foo, not foo-internal.
@daleif don't put large code blocks in an if-fi nested region, it's a source of future bugs... If you are worried about people scrolling past the error in batch mode, make the error fatal eg \RequireLuaTeX and similar commands in iftex.sty simply stop at that point if the test fails.
@daleif as i say I'd always avoid having an \if...\fi covering an extended region, it's just too easy to have code using an if that goes wrong there \newif\ifoo being the classic example. less likely in expl3 code that mostly hides primitive ifs but still....
@daleif that is: compare your two versions if code is \newif\ifabc \ifabc abc\fi
With regards to the implicit \ExplSyntaxOff at the end of an ExplClass, is it then save to end a class with a conditional \endinput? (I'm assuming it is). Wanted to only include the last part of the class if a certain option was active
@daleif yes that's what I mean any code that runs at end of file rather than from a command within the file will run on \endinput as latex really can't tell the difference
