# Minted: Is there a Unicode/non-ASCII character that works for escapeinside?

Documentation for fancyvrb and minted warn that users should not expect any character to work in a listing that would not work in verbatim. But they don't foreclose on the possibility, and the idea of using an escape character that would never appear in source code is a tantalizing prospect: juggling escape characters is a nuisance; much better is to set one and forget it.

I'd been using listings until a few days ago, when I discovered that \lstinline has problems in vertical mode (e.g. \parbox) that I understand minted does not have. And yet listings has the advantage that it allows escaping to LaTeX with non-ASCII characters—I've been using “©” without trouble—whereas minted hasn't accepted any of the dozen or so non-ASCII characters I've tried with escapeinside so far.

Does one exist?

\documentclass{article}

\usepackage{fontspec}

\usepackage{minted}

\usepackage{unicode-math}

\begin{document}

SELECT ©$$a ∈ A$$©
\end{minted}

\end{document}


I'm compiling with lualatex, if that matters, with option --shell-escape and have Pygments version 2.2.0 installed and functioning.

escapeinside can work with non-ASCII characters. But only if you can avoid encoding issues.
The escapeinside characters are passed to Python and Pygments as part of a pygmentize command that is executed via shell escape. This fails under Windows because the characters are encoded as utf8, but by default Python interprets the pygmentize command arguments (sys.argv) as cp1252 (at least with PowerShell). Under Linux, it also fails, and the © is turning into the Unicode sequence \udcc2\udca9. I'm not sure what set of encoding issues led to this, since everything seems to be utf8 by default.
If you can get everything using the same encoding, then it will work (I tried editing Pygments' cmdline.py to force utf8 under Windows), but getting that to happen may be difficult in some cases.
• @LaTeX2enub1336 I can't suggest anything for Linux, because I'm still not sure what is happening there. I'm working on plans for minted 3.0, and it will likely take a different approach to option handling that will avoid these sorts of issues. So non-ASCII escapeinside will probably work eventually without needing to worry about encodings. – G. Poore Aug 4 '17 at 11:30