# publiclatex3/svn-mirror

### Subversion checkout URL

You can clone with HTTPS or Subversion.

# xparse: \NewDocumentEnvironment and spurious environment name#107

Closed
opened this Issue · 9 comments

### 3 participants

Using xparse 2012/08/14 v4091 consider the following code:

\documentclass{article}

\usepackage{xparse}
\NewDocumentEnvironment{test}{og}{start:}{end!}

\begin{document}

\begin{test}
middle
\end{test}

\end{document}


This should look like

start: middle end!

but actually gives

start: middle end!test

This only happens with certain arg specs, the only ones I found were »og« and »go«.

Regards

Owner

Could you check the GitHub version, or the very latest CTAN update, as this looks like issue #104 which is fixed.

Indeed! With the latest CTAN version it works as expected.

Owner

OK, closing as a duplicate of #104.

However, if I use the CTAN (2012/08/29) the following example that worked previously

\documentclass{article}
\usepackage{xparse}
\NewDocumentEnvironment{test}{o}{start}{stop!}
\begin{document}

\begin{test}
middle
\end{test}

\begin{test}[]
middle
\end{test}

\end{document}


now gives

start middle stop!NoValue-
start middle stop!test

(Might that be because I only used the new xparse and not the whole kernel?)

Owner

Something is still not right here: I will sort then I guess make Robin's life a misery by doing a rapid CTAN update!

Owner

OK, the next time Will updates GitHub this will get closed: I've checked in a fix, and will probably sort out a test later this evening for this. I'll probably update CTAN to get this out, despite the fact that I've only just done one!

closed this issue from a commit
 joseph Revert 'optimisation' from checkin 4010 (fixes #107) The issue here is that \tl_tail:N will remove braces around the saved argument if there is exactly one argument. The \use_none:n method does not do this as the arguments themselves are never tocuhed: only the unneeded token is removed. git-svn-id: http://www.latex-project.org/svnroot/experimental/trunk@4165 de43f980-851b-0410-b2f7-c40aca1f87e0 936aab1
closed this in 936aab1
referenced this issue from a commit
 joseph Add testfile for \tl_head:n/\tl_tail:n awkward cases See for example issue #107 for why this behaviour is important to be aware of. git-svn-id: http://www.latex-project.org/svnroot/experimental/trunk@4167 de43f980-851b-0410-b2f7-c40aca1f87e0 7878a28
referenced this issue from a commit
 joseph Fix issue with \tl_tail:n and associated changes As shown up by issue #104 and issue #107, the old definition of \tl_tail:n was problematic as it stripped braces from the output if there was exactly one braced item in the 'tail'. The fix here means that tail is always left exactly as-is by \tl_tail:n. The documentation now reflects that. As a result of the change, xparse can now use \tl_tail:n reliably, allowing the slightly awkward code we had there to be removed once again. At the same time, \tl_tail:w is defected and cannot be fixed (more than one expansion will always be required). It is therefore deprecated: announcement to LaTeX-L upcoming. While \tl_head:n always strips braces, the old definition did not always behave correctly with \q_stop in the input. The new definition here should be robust against any reasonable input: you only get an issue if you deliberately use two @ tokens with appropriate catcodes followed by \q_stop, which seems acceptable. Some of the documentation has been tightened up a little, so that hopefully we can ues 'item' clearly to describe the behaviour not only of \tl_(head|tail):n but also of other functions in l3tl. git-svn-id: http://www.latex-project.org/svnroot/experimental/trunk@4185 de43f980-851b-0410-b2f7-c40aca1f87e0 26ecfa5

I'm sorry if this question has an obvious answer: is the fix supposed to be in xparse 2012/08/29 v4160? I'm still getting the (same) wrong output from my second example.

It's solved in the SVN but not on CTAN yet. We are just sorting out a related change, as the problem here pointed up a flaw in \tl_head:n and \tl_tail:n. Hopefully I can do a release by tomorrow.

Ah I see. Thanks!

referenced this issue in urdh/skrapport
Closed