when I declare a macro with suffix, its use inside a \uppercase commands doesn't work.

See the MWE


\newcommand{\AcCan}{\emph{Actes des Apôtres} canoniques}
\WithSuffix\newcommand\AcCan*{\emph{Actes des Apôtres}}

{\MakeUppercase{Les \AcCan}}

If delete the \WithSuffix line, it's ok.

  • 3
    That isn't a MWE, it just generates ! LaTeX Error: \usepackage before \documentclass. – David Carlisle Mar 12 '15 at 22:04
  • you are right. I have forgotten to copy it... – Maïeul Mar 13 '15 at 9:59

Here is a method which will allow you to still use \AcCan and \AcCan*, without extra braces. See the small caveat in the code comments and below.

Extra caveat added in update

% -*- coding: iso-latin-1; -*-

% First we patch LaTeX \MakeUppercase and \MakeLowercase
% As far as I can tell, these redefinitions should have nil impact 
% and very few incompatibilies, if any.
      \protected@edef\reserved@a{\uppercase{#1\empty}}% \empty added
      \protected@edef\reserved@a{\lowercase{#1\empty}}% \empty added

% Then we can define expandable variant \AcCan* 
% The collateral effect is that \AcCan act as a brace remover: just be aware
% that \AcCan {<stuff>} will be as original \AcCan <stuff> and never use
% \AcCan {stuff * more stuff} as it will end up in error: I am perhaps not  
% providing it the most robust way (and I don't use e-TeX whose \detokenize
%  would help for alternatives), but in 99% of cases it should be ok.

% Important caveat: if \AcCan is used as part of the argument of a macro,
% like \section then, if it *last* therein before the closing }, it *must* 
% be followed by {}, or \empty, or \relax.

\catcode`_ 11
% helper macro,
\long\def\GobToStar #1*{}
% expandably enhancing \AcCan with a starred variant
\long\def\AcCan #1{\GobToStar #1\AcCan_s *\AcCan_ns #1}
% the \long is in case \AcCan is last on a line, itself followed by empty line.
\def\AcCan_s *\AcCan_ns *{\emph{Actes des Apôtres}}% starred variant
\def\AcCan_ns {\emph{Actes des Apôtres} canoniques}% non starred variant
% The above could easily be automatized:
% \MakeStarredVariant\Macro{replacement text for \Macro*}
% with the same limitations as pointed above
\catcode`_ 8






enter image description here

When I said in 99% of the cases it should be OK, this just meant: avoid input like \AcCan {stuff} (\AcCan*{stuff} has no issue and \AcCan {stuff} is a problem only if stuff contains *.) In general this will be automatic because I guess AcCan will be followed either by a letter, punctuation sign, or \par, or } if used in \section for example.

Important: in the latter case, (last argument in \section) or more generally whenever \AcCan is a last component of some argument to some macro \macro {....\AcCan }, it is recommended to follow it by {}, or \empty or \relax:

\macro {....\AcCan{}}

This is mandatory for \section for example. For \textbf however it is not needed (because internally we will not end up in a situation \AcCan} where expanding \AcCan will raise an error).

If used as last argument to a macro, even not writing to a file, there is also a smallish risk that the macro will itself add some {stuff} after \AcCan before expanding \AcCan. If stuff contains a * there will be a problem. The possibility appears remote. In case of a compilation error in such an unlikely situation, replace \AcCan by \AcCan {} or \AcCan\empty and it should be fine. (except if the macro is very obstinate in doing bad things)

The \AcCan will be expanded whenever written to the aux (hence to the toc, it first goes to the aux) file, which appears to be no problem either: at this time it will once and for all look for a * and expand to one of the two possibilities.

But one must pay attention to cases when it is the last piece in the macro argument. Follow it by {}, \empty or \relax then.

  • I am quite anxious to redefine \MakeUpperCase.... – Maïeul Mar 13 '15 at 10:03
  • The redefinition is truly benign. It adds a single \empty token which will disappear. The modification can only break macros designed to be used as the very last piece of an argument to \MakeUppercase. It is improbable such a thing exist. – user4686 Mar 13 '15 at 10:36
  • I will think at what is better in my case, because in any case I should change some line in my main text (indeed, I wanted to do something like \section{\AcCan*}. – Maïeul Mar 13 '15 at 10:40
  • \section{\AcCan*} is ok, it is only \section{\AcCan} which should be replaced by \section{\AcCan{}} for example. – user4686 Mar 13 '15 at 10:42
  • Ok ! But as I see, your solution make create two new commands \AcCan_s and \AcCan_ns. So I could call them directly in section... I any case, thanks. I think you'r solution is the best for using only one command with starred variant. – Maïeul Mar 13 '15 at 10:45

If you do \show\AcCan after the \WithSuffix line, you see

> \AcCan=\protected macro:
->\WSF@suffixcheck \AcCan .

which means that \AcCan survives unchanged an \edef, which is what \MakeUppercase does to its argument (in the \protected@edef form).

Thus the \uppercase that's eventually performed still sees \AcCan and so does nothing to it.

If you are willing to accept writing \AcCan{} and \AcCan*{} then you can do it:



  \emph{Actes des Apôtres}%
  \IfBooleanF{#1}{ canoniques}%


{\MakeUppercase{Les \AcCan{}}}

{\MakeUppercase{Les \AcCan*{}}}


enter image description here

  • ok, but is there any solution? I can't expand \AcCan before \MakeUppercase (or I am not able with \expandafter) – Maïeul Mar 12 '15 at 21:05
  • @Maïeul Not that I see. If the macro had a mandatory argument something could be done. – egreg Mar 12 '15 at 21:06
  • ok, but it's not the case – Maïeul Mar 12 '15 at 21:14
  • @Maïeul If you accept writing \AcCan{} and \AcCan*{}, then something is possible. – egreg Mar 12 '15 at 21:24
  • Yes, I have to look how many time I use the shorter form, without arg. Because I wouldn't like to have to made many change. For the present case, I have avoided the problem by typesetting directly \emph{Actes des apôtres} and not \AcCan* – Maïeul Mar 13 '15 at 10:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.