Achim wrote: > > the problem with this and perhaps the problem with the whole mechanism > > is that a lot of people have learned to write environments like this: > > > > \newenvironment{foo}{...\quote ...}{ ... \endquote ...} > > > > ie without using \begin/\end internally. > > > > if all such things like \quote internally use \EndThisEnviornment then > > guess what happens. so this needs some thoughts. > > > > a) do not allow above usage > > IMHO such hacks as above shouldn't be allowed anyway. If someone directly > accesses internals of some package instead of using the defined > interface he deserves his code breaking when the implementation is > changed. In theory I do agree with this but in practice one might have to be more careful simply because this usage is so common. Unfortunately I was even used (perhaps even is) by Leslie Lamport in its original class files. It also has the side-effect of not changing \@currenvir and some people have used this deliberately to get proper error messages for their environments. > Besides, what happenes if someone uses two nested lists in the > above way? So you have the problem regardless of whether all templates > share a common name or each uses its own one. true, which is why I said one probably has to think about it more generally. > One way to allow hacks like this could be to define \newenvironment as > > \newenvironment <name> <begin-code> <end-code> := > \def\<name>{ > \begingroup > <begin-code> > } > \def\end<name>{ > <end-code> > \endgroup > } > > that is, to move the \begingroup, \endgroup from \begin and \end > into the \foo, \endfoo commands. That could be a solution to get the best of both (costing a few tokens per defined environment but this is not really an issue) For the moment I will stick with a single command \EndThisEnvironment and see how it develops. My note was mainly to record that there is something to be thought about further at some stage cheers frank