# stuff following minted environment causes error

Consider the following code:

\documentclass{article}
\usepackage{minted}

\begin{document}
\begin{minted}{python}
a = 0
\end{minted} % this comment is a problem
\end{document}


It causes the following error:

! FancyVerb Error:
Extraneous input  % this comment is a problem\end{}' between \end{minted} and line end


Moving the comment to the next line resolves the error. It seems that nothing except for spaces may be on the same line after an \end{minted}. This is also the case for environments defined by \newminted. A verbatim environment on the other hand does not seem to have a problem with code following on the same line.

I have not seen this behavior being described in the minted documentation.

Can anyone explain what the problem is that nothing may follow a \end{minted} on the same line?

• Probably it doesn't scan for the environment end, but because it's verbatim for the exact string. That's why spaces, which can be gobbled at end are no problem, but those comments are. – TeXnician Apr 19 '17 at 14:16
• The minted environment is a type of verbatim environment. For any verbatim environment you want to end the \end{...} command to be on a line alone since by scanning for that command on a line alone the environment knows when to stop scanning. – Herb Schulz Apr 19 '17 at 14:38

The minted package uses the fancyvrb package underneath the hood for its verbatim environments (see p.13 in the minted manual, for example), and the error is already present when you use that package instead (also, as the error message says, it is actually given out by FancyVerb, not minted itself; hence why it is not in the minted documentation I reckon). This code will produce the same error:

\documentclass{article}
\usepackage{fancyvrb}
\begin{document}

\begin{Verbatim}
This is verbatim code
\end{Verbatim}%

\end{document}


If we wish to trace the origins of the error:

The Verbatim environment scans its contents line-by-line, see section 12.10 of the fancyvrb documentation, Line-by-line Scanning. And indeed, this is where we meet the definition of this error. \FV@BadEndError, thrown by the aptly named \FancyVerbGetLine command.

The \FancyVerbGetLine command calls \FV@BadEndError on this line in the fancyvrb source code:

\ifx\@tempa\FV@EnvironName%            % True if end is found

We have to check the argument of the first \end{} in each line, compare it with \FV@EnvironName, and return \iftrue if it matches and \iffalse otherwise.
The trouble is that at this point \@tempb should be \end{}, but instead it is now %\end{}. Thus, the second \ifx is false, and the error is thrown (\@tempa from the previous line is Verbatim btw.).
In the end, this almost amounts to a straight-up string comparison, at least as far as I can tell (not only does fancyvrb test for an \end{}'s argument, but it also tests whether there is nothing else on that line), with the slight exception of ignoring whitespace on the line: That does indeed get stripped away, thereby not tripping up the \ifx (can be tested by looking at the contents of \@tempb if you hack the fancyvrb` source code a bit to output that; it contains no spaces).