Package warning interferes with macro expandability - TeX

samcarter

@Skillmon, re: [your answer](#a7753), Oh, it even works with `\ifluatex...\fi`, so I could have it in the package for luatex users.

samcarter

@Skillmon, re: [your answer](#a7753), Thanks a lot for your answer! It is interesting to see!

samcarter replying to Skillmon

Personally, I'm looking for an engine-independent approach, but if you haven a solution for lua, it might be useful for other users with the same question.

Skillmon

@samcarter, re: [your question](#question), I guess a LuaTeX-only answer isn't ok?

samcarter

(I switched to build-in mechanism to minimise dependencies)

samcarter replying to Skillmon

1 . Sorry, "easy" was the wrong word. I was just wondering if I was missing some dedicated mechanism or if that's the way to go.    
  
2/3 . Thanks a lot!
  
4 .  it was more curiosity/for experimentation :)

Skillmon

The key definition interface of just `expkv` is even lower level than `keyval` (which has an optional argument to define a default value). That was a deliberate design decision I took, just giving it the bare minimum and optimising that for speed. Every additional feature is part of other packages building atop that core (`expkv-def` providing common key types and a key=value based interface to key-definitions, `expkv-cs` providing a simple way to define fully expandable key=value macros, `expkv-opt` to parse options for 2e classes and packages)

Skillmon replying to samcarter

1. what's uneasy about this? You just define a macro.
2. if you use the plain interface of `expkv` to define keys, no, there's no easier way (regardless of the used metrics, this is the only way next to `\ekvset{busyPanda}{scale=1.0}` after `\ekvdef...`))
3. if you use `expkv-def`'s interface it's very `pgfkeys` or `l3keys` alike, just a bit inverted: `\ekvdefinekeys{store scale = \busyPanda@scale, initial scale = 1.0}`  
4. don't choose `expkv` just to please me (I like it, yes, but I created it, so I'm `\infty`-biased, and for contraction work I still choose `l3keys` over it -- it caught up to `expkv` recently since it supports an expansion notation now, though a slightly less powerful one)

samcarter replying to Skillmon

Is there an easier way to set a default value than  
```  
\ekvdef{busyPanda}{scale}{\def\busyPanda@scale{#1}}
\newcommand*\busyPanda@scale{1.0}  
```  
?

Skillmon replying to samcarter

you could add a hook to `begindocument` to at least check whether the main font is known.

Skillmon

But as I said, feel free to ignore, don't change just to please me (though the less packages load `xkeyval` the better -- it's slowish and introduces even more brace bugs over `keyval`)

Skillmon

(though since you only have the `scale` option, which is unlikely to get fragile arguments, I guess using one of the legacy solutions is fine as well; I'd still prefer a modern solution for any new packages myself)

Skillmon

I'm not sure whether `scrbasic` hooks into the "future" options, though.

Skillmon replying to samcarter

For package options I'd aim to use any solution which supports a) the new raw option lists, and b) the option-clash-avoiding solutions. AFAIK (was a while when I last did a small survey of all the available options) that leaves you with built-in, `expkv-opt`, and maybe KOMA-script's `scrbasic`.

Skillmon replying to samcarter

For my own code: I like `expkv` (don't ask me why), but more sincere and weighing the options: You already use L3-code, just go with LaTeX's built in key=value options processor.

samcarter replying to Skillmon

What would you suggest instead?

samcarter replying to Skillmon

It was so easy to copy the code from another package :)

Skillmon

Can I have a feature request: Don't use `xkeyval`. (feel free to ignore :P)

samcarter replying to Skillmon

Thanks however for noticing!

Skillmon replying to samcarter

ok (just wasn't sure whether that was an oversight or not).

samcarter replying to Skillmon

It will work after the first release (the script to do releases will compile and commit it)

Skillmon replying to samcarter

the documentation linked to by your README gives a 404.

samcarter replying to Skillmon

Not really, my current plan is to have this as a standalone macro: https://github.com/samcarter/panda/blob/main/busyPanda.sty

Skillmon replying to निरंजन

It's not possible with the example given as `\rule` evaluates the sizes inside a `\hbox`, so a group. Flags are local only. The basic idea of flags is exploiting the side effect of `\csname` to set an undefined control sequence to `\relax`, which happens fully expandably. They are basically something like `\expandafter\@gobble\csname MyFlag\endcsname`, but in `expl3` (and `expkv-cs`) they use names with a numerical part, raising a flag further is `\csname`-ing the next item in the sequence.

निरंजन replying to Skillmon

Curious. Can you show how to do that with the example she has given?

Skillmon replying to samcarter

do you have control back in a close spot? If so, you can raise a flag (that's fully expandable) and act accordingly.

Skillmon replying to Joseph Wright

wait, "we" have an idea? I have none... Was Bruno in a meeting?! :P

samcarter replying to निरंजन

Undoubtedly!

निरंजन replying to samcarter

Indeed ugly, but I am sure there is some use case that requires it :)

samcarter replying to निरंजन

Thanks! What an ugly error :)  
  
Also found some more reading material on the topic https://topanswers.xyz/tex?q=3405

निरंजन replying to samcarter

```
\documentclass[varwidth,border=1pt]{standalone}

\ExplSyntaxOn
\msg_new:nnn { quack } { test } {
  Font~ #1~ not~ in~ lookup~ table
}

\cs_generate_variant:Nn \msg_expandable_error:nnn { nne }

\makeatletter
\NewExpandableDocumentCommand { \busyPanda } { m } {
  \str_case_e:nnF { \f@family } {
    { cmdh  } { 0.785169 }
    { cmss  } { 1.16462  }
    { cmtt  } { 1.14753  }
    { cmvtt } { 1.28199  }
    { cmbr  } { 1.03998  }
  } {
    \msg_expandable_error:nne { quack } { test } {
      \f@family
    }
    1
  }
}
\makeatother
\ExplSyntaxOff

\newcommand*{\bamboo}{%
  \rule{\busyPanda{}\fontcharht\font`I}{\fontcharht\font`I}%
}

\begin{document}
cmr: \bamboo

\fontfamily{cmbr}
cmbr: \bamboo
\end{document}
```

samcarter replying to Joseph Wright

Thanks a lot for your comment! I guess I will simply document how users can spot unsupported fonts and patiently wait and see if these ideas might solve this in the future.  
  
I'd be also very grateful if you could post a short example with an expandable error as an answer!

Joseph Wright

Anything involving a write is non-expandable - that includes all the classical `\Package...` things. We have some devious code in `expl3` for expandable errors and do have an _idea_ of how to produce warnings, but the restrictions on the approach (very short text, etc.) mean it's not really generally useful.

1 Answer