The relationship between "<..>" and "*"

[josephwright]

In adding support for \includegraphics, I am wondering what the expectation is for ordering "<...>" and "*"? Trying in beamer, I think something is bust as I can't get

\documentclass{beamer}
\begin{document}
\begin{frame}
  \includegraphics<1->*{example-image-a}
  \includegraphics*<2->{example-image-a}
\end{frame}
\end{document}

to work at all - so perhaps 'no stars'?

(The issue with * seems to be my fault in supporting graphics syntax - but no-one has noticed since 2017 - then again, no one noticed graphics syntax didn't work from when Till wrote beamer to 2017 ...)

[davidcarlisle]

the * form is really just there for graphics-with-no-x it's rather pointless with graphicx If it takes more than a line of code to support, I wouldn't bother

[josephwright]

Well we are using ltcmd so I can set up the sig. s D <> { all } s and see if there is a star either side - but I think both look a bit awkward, and wonder if it might be best to say simply 'we only support the keyval graphicx syntax' and more generally to say 'do not add overlay specs to starred commands'.

[samcarter]

I've just run a search through a collection with 7500 code snippets, most of them beamer, not a single one used \includegraphics*{...} :)

[davidcarlisle]

But putting \includegraphics to one side, there may be other star forms where it is needed, so to answer your original question:

I think the expectation is definitely

  \includegraphics*<2->{example-image-a}

not

\includegraphics<2->*{example-image-a}

The LaTeX Book and most tutorials mostly document the star forms as an alternative command not as a kind of weird optional argument
if you believe the documentation \includegraphics * would be like \includegraphic s with a space in the command name, so the * should closely bind to the command name.

[samcarter]

Looking through other beamer commands, they seem to be inconsistent:

• \onslide*<3>
• \section<beamer>*{Outline}

[davidcarlisle]

I think \section*<...> is more logical, but I guess you may have to support <>* (or both) in the end depending on what the final story is re beamer compatibility.

[josephwright]

I'm not too worried about beamer compatibility to this level: we are re-examining things plus we likely will end up providing some 'do more compatible stuff' package to aid the transition.

At the moment, I've not added support for * to \onslide anyway, and I think like @davidcarlisle that \section*<...> is better - so I'll probably go that way.