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