# Missing middle delimiters when reDeclarePairedDelimiterInnerWrapper is used

I'm using \DeclarePairedDelimiter (from mathtools) to define a \paren macro as follows:

\providecommand{\given}{\:\vert\:}
\DeclarePairedDelimiterX\paren[1]{(}{)}{%
\renewcommand{\given}{\:\delimsize\vert\:}#1%
}


This works as expected. But, following the answer to this question, I used \reDeclarePairedDelimiterInnerWrapper to fix the position of sub/superscripts that follow:

\reDeclarePairedDelimiterInnerWrapper{\paren}{nostar}{#1#2#3}


Now using \paren{a \given b} produces (a b), instead of (a | b). (Ie the \given symbol is omitted entirely). Using \paren[\big]{a \given b} or \paren*{a \given b} work just fine though.

Any ideas?

• Update: Using \paren[\relax]{a \given b} also works as expected. It only fails when the size argument is omitted entirely. – gi1242 Apr 25 '17 at 20:29
• It happens that \MHempty, which is the default value when the optional argument is missing, is redefined to \@gobble at some point: this is done on purpose, but apparently it is done at the wrong time. – egreg Apr 26 '17 at 7:23
• Thanks. After experimenting a bit, I'm convinced it is a bug. I'll report it. Any idea if there is a simple work-around...? – gi1242 Apr 26 '17 at 17:45
• We need the \let\MHempty\@gobble to remove the addition of l/r when there is no scaler. I think the easiest to to is to set \MHempty back to {} after we have used it in the front and end scalers. – daleif Apr 27 '17 at 8:02

As @egreg mentions this is due to \MHempty being redefined to \@gobble for the surrounding fences. This is usually done via \mathopen/close{...} which acts as a group and this \@gobble is localised. With the definition of the wrapper, the \mathopen/close and the grouping is gone and \delimsize which points to \MHempty when there is no scaler, is now \@gobble which eats the middle part.

The easiest method for this to works without grouping is to set \MHempty back to {} after its use in the outer fences.

The code below seems to work.

Please note that in the next release there will be three wrappers, autoscaled, non-scaled and scaled, where the non-scaled will use \mathopen/close... not \mathopen/close{...} which has side effects when no scalers are used.

\documentclass[a4paper]{memoir}
\usepackage{mathtools}
\MHInternalSyntaxOn
\makeatletter
\def\MHempty{}
\def\DeclarePairedDelimiterX#1[#2]#3#4#5{%
\@ifdefinable{#1}{
\MT_paired_delimx_arg_test:n{#2}
\MT_delim_default_inner_wrappers:n{#1}
\@xp\@xp\@xp
\newcommand
\@xp\csname MT_delim_\MH_cs_to_str:N #1 _star:\endcsname
[#2]
{
\begingroup
\def\delimsize{\middle}
%\mathopen{}\mathclose\bgroup\left#3 #5 \aftergroup\egroup\right#4
\@nameuse{MT_delim_\MH_cs_to_str:N #1 _star_wrapper:nnn}
{\left#3}{#5}{\right#4}
\endgroup
}
\@xp\@xp\@xp
\newcommand
\@xp\csname MT_delim_\MH_cs_to_str:N #1 _nostar:\endcsname
[1][\MHempty]
{
\begingroup
\def\delimsize{##1}
\@nameuse{MT_delim_\MH_cs_to_str:N #1 _nostar_inner:}
}
\@xp\@xp\@xp
\newcommand
\@xp\csname MT_delim_\MH_cs_to_str:N #1 _nostar_inner:\endcsname
[#2]
{
%\mathopen{%
%  \let\MHempty\@gobble
%  \@xp\@xp\@xp\csname\@xp\MH_cs_to_str:N \delimsize l\endcsname #3}
%#5
%\mathclose{%
%  \let\MHempty\@gobble
%  \@xp\@xp\@xp\csname\@xp\MH_cs_to_str:N \delimsize r\endcsname #4}
\@nameuse{MT_delim_\MH_cs_to_str:N #1 _nostar_wrapper:nnn}
{
\let\MHempty\@gobble
\@xp\@xp\@xp\csname\@xp\MH_cs_to_str:N \delimsize l\endcsname #3
\def\MHempty{}
}
{#5}
{
\let\MHempty\@gobble
\@xp\@xp\@xp\csname\@xp\MH_cs_to_str:N \delimsize r\endcsname #4
\def\MHempty{}
}
\endgroup
}
\DeclareRobustCommand{#1}{
\@ifstar
{\@nameuse{MT_delim_\MH_cs_to_str:N #1 _star:}}
{\@nameuse{MT_delim_\MH_cs_to_str:N #1 _nostar:}}
}
}
}
\makeatother
\MHInternalSyntaxOff

\providecommand{\given}{\:\vert\:}
\DeclarePairedDelimiterX\paren[1]{(}{)}{%
\renewcommand{\given}{\:\delimsize\vert\:}
#1%
}
\reDeclarePairedDelimiterInnerWrapper{\paren}{nostar}{#1#2#3}

\begin{document}

$\paren{ a \given b }$

\end{document}

• This works perfectly, thanks a lot! From what you say above, do I understand that you are going to include a fix in future releases of MathTools? – gi1242 Apr 27 '17 at 15:53
• @gi1242 of course – daleif Apr 27 '17 at 16:26