\only vs onlyenv, etc.

[josephwright]

In beamer, we have both command and env. versions of all of the 'overlay' functions. I wonder if it might be better only to have these as environments - would simplify the naming, and whilst it's a bit longer to write

\begin{only}<+->
  Some content
\end{only}

than

\only<+->{some content}

if avoids catcode, etc., issues plus the awkward naming problem. We likely could cover the existing beamer model by checking \@currenv at the start of each command - so if they are used 'old style' would issue a warning.

Thoughts?

[samcarter]

Personally, I like the environments.

For some reason the vast majority of current beamer users however seem to use the macros rather than environments, so this would affect a lot of users.

So the question probably is: how compatible should xbeamer be?

I would prefer just the environments (with the warning for old style macros) to get a solid base for xbeamer.

[josephwright]

Like I said, I think using the same approach as is used for \frame at the moment we could retain the current syntax but with warnings, and an option to forbid it. I guess \alert is the one that we might want to keep as a first-class command.

[josephwright]

(I'm thinking about actionenv at the moment, which is what drives the question.)

[samcarter]

Do you plan to keep the distinction between actions and overlays?

[samcarter]

I guess \alert is the one that we might want to keep as a first-class command.

For symmetry reasons, I would maybe suggest three macros: alert, structure and something which uses the example colour. This way one could use the colours of these macros as parent for blocks and other elements.

[josephwright]

Do you plan to keep the distinction between actions and overlays?

As in <+- | alert@.>? In that case, yes - I can't find a single term to describe this idea.

[wspr]

My gut reaction is that I don’t like the longer syntax. Is the catcode thing really such a big issue if the command versions are so popular? Is it really that awkward to have all the {zzzenv} versions? Especially when the \only is being used with a short argument, having the full blown environment syntax creates a messier source… although I recognise that source prettiness is in the eye of the beholder :) It’s a bit annoying that LaTeX has this longstanding conflation of environment vs command syntax. But I’m not sure that ditching commands entirely as a result is the best idea. If you can hack it so that the command and environment versions look the same but have different code paths, this might be a good place to start a new precedent. But otherwise my 2c would be to err on the side of consistency and stick with the current syntax.

[josephwright]

My gut reaction is that I don’t like the longer syntax. Is the catcode thing really such a big issue if the command versions are so popular? Is it really that awkward to have all the {zzzenv} versions?

It's more that the naming is quite ugly - but like you say ...

It’s a bit annoying that LaTeX has this longstanding conflation of environment vs command syntax

Indeed - we are stuck with that, unfortunately (one of the things that the mythical LaTeX3 might have sorted that we now can't address).

[Skillmon]

How about we switch to a catcode-friendly code path on fragile frames? The command versions only need to be category code friendly on fragile frames anyways since otherwise the category codes are fixed. So use a rescanning variant in fragile, use the normal commands otherwise.

[wspr]

I’m not convinced it’s not too late to change the way environments in LaTeXe work… e.g., \begin{foo} checks if \csname foo@***@***.***\endcsname exists and if so uses that definition, otherwise falls back to \foo. That kind of checking is trivially fast and ensures compatibility since the definition of \foo itself doesn’t need to change. With the intention that this is to streamline definitions where different code paths are needed for commands vs environments (because catcodes), or \alert{…} conceptually is the same as \begin{alert}…\end{alert} but they are not strictly the same thing, or where it’s not sensible to have both commands defined (e.g. \begin{LaTeX}\end{LaTeX} is obviously useless…). This is the wrong place to talk about it I guess, but would it make sense to think about introducing it? Looking back into the long history of LaTeX development, I would be surprised if there is such a thing as “too late” to introduce something new :)

[FrankMittelbach]

This is the wrong place to talk about it I guess, but would it make sense to think about introducing it? Looking back into the long history of LaTeX development, I would be surprised if there is such a thing as “too late” to introduce something new :)

I like the idea too, but we have to be aware that this is a change from documented behavior, that is we are then going to introduce 2 classes of environments:

• those that allow for \foo ...\endfoo to work
• and those for which that syntax would lead to chaos

This means that wee need to carefully document that, say, all environments, using \NewDocumentEnvironment can not be used without \begin \end and we do need to check across CTAN if we would break existing code that way!

[cfr42]

I can't say I've ever used the environment versions of \only etc., but how would they work with, say, pgfkeys?

\tikzset{%
     alt/.code args={<#1>#2#3}{%
        \alt<#1>{\pgfkeysalso{#2}}{\pgfkeysalso{#3}} 
      },
}

This gets used in pgf/tikz/forest etc., but I think this would be harder - or, at least, less obvious - if only environments were available?

[josephwright]

Interesting point: I'd not noticed this usage (I tend to use overlays very sparsely and in a pretty focussed way).

[samcarter]

That's a good point! Or anything else which needs to have no group around it.

[josephwright]

I think this decides the point, though I do like @wspr's idea for extending the kernel to allow both \alt and \begin{alt} to work with separate paths.