First I want to make clear that I'm a LaTeX beginner, so I'll be detailed because I just have no clue about the origin of my problem. I'm using TeXstudio 2.12.6

I'll provide context: I have been researching how to write greek characters directly in the math mode and having them recognised as so when compiled. I.e., I wanted

α = xy^2 + β

being recognised exactly as

\alpha = xy^2 + \beta

Ι finally figured out here how to achieve it: Type Greek letters in Math Mode using Greek keyboard, just using the preamble indicated there (it's in the accepted answer):



Although there's some differences between the original one given in the answer and mine here:

  1. the babel package flags were originally [english, greek], while mine here are [greek,spanish]: Order in the flags matters and this way spanish is the principal language in my code (as I wanted it to be).
  2. I'm using {amsmath,amssymb,dsfont} too.
  3. I'm using report instead of article.

Now my problem: Recently I've discovered that in math mode when using commands it's not necessary to use braces to encapsulate arguments. In other words, TeXstudio does identify \binom a b exactly as \binom{a}{b}. BUT, when I use a greek letter in an argument given without braces, it won't compile and pops up this two errors:

Package inputenc Error: Unicode char �\endgroup (U+3CE)(inputenc) not set up for use with LaTeX. \binom α

Package inputenc Error: Keyboard character used is undefined(inputenc) in inputencoding `utf8'. \binom α

When writing \binom α b in math mode.

Another example: It happens a similar thing when writing overbrace β instead of overbrace{β} in math mode. (In both cases, overbrace{β} and binom{α}{b} do work).

Please help. And thank you in advance.

  • 2
    Why would you like to type the commands this way? – Michael Fraiman Dec 7 '17 at 12:46
  • 1
    That is (I think) because α is a multi-byte unicode character. Without the grouping, only the first byte is absorbed as the argument, before inputenc can sort it out as a multi-byte unicode character. Keep in mind the concept of unicode characters was developed long after TeX's argument-absorbing mechanisms were in place – Steven B. Segletes Dec 7 '17 at 12:51
  • 2
    You should always type \binom{x}{y}. Then your problem vanishes. Typing \binom x y as well as \frac 1 2 easily leads to problems. – egreg Dec 7 '17 at 13:01
  • 2
    I would add that using the braces is the prescribed TeX syntax. While sometimes, one can avoid it, such shortcuts should not be encouraged, precisely because they bite you at times like this. – Steven B. Segletes Dec 7 '17 at 13:03
  • @MichaelFraiman I was just being lazy in writing braces. – Elías Guisado Dec 7 '17 at 18:07

You simply can't get what you'd like. You have to consider that \binom takes two arguments and, if a brace doesn't follow, the first argument will be the next token; similarly for the second argument.


When you type \binom α b, TeX actually sees

\binom <CE><B1> b

so it does the same as if it had found

\binom{<CE>}{<B1>} b

where <CE> and <B1> represent characters with the indicated hexadecimal code. Remember that TeX doesn't really know about Unicode and UTF-8.

The character α is represented in UTF-8 by two bytes (the ones I showed above). The inputenc package makes <CE> into an active character, whose action is to examine the next byte and take the appropriate action, in this case, being followed by <B1> it changes the two bytes into \alpha that the package alphabeta has redefined to give


So, if α appears in math mode, you'll eventually find the same as if typing \alpha in the traditional setup.

But the important fact is that <CE> must be followed by another byte so that their combination points to the right definition. Which doesn't happen if you have \binom α b.


Always type braces in that situation. You gain nothing by typing \binom n k instead of the clearer \binom{n}{k}.

And if you try $X_\notin$, you'll learn to also type $X_{1}. A good editor will do that for you.

Addendum: the whole story

Actually the whole thing is a bit more complicated, even the explanation above is substantially correct. If you want to know the whole story, here it is.

Following the expansion of \binom, the input \binom α b is transformed into

\genfrac (){0pt}{}<CE><B1> b

and \genfrac is a four argument macro, that in turn calls \@genfrac and the input becomes

\@genfrac\relax\@@abovewithdelims{(){0pt}} <CE><B1> b

and finally, since \@genfrac is a five argument macro, this becomes

{\relax{\begingroup <CE>\endgroup\@@abovewithdelims()0pt <B1>}} b

As you see <CE> is followed by \endgroup and, indeed, the error message is

! Package inputenc Error: Unicode char ?\endgroup (U+3CE)
(inputenc)                not set up for use with LaTeX.

(the question mark represents the prefix <CE>). After some other errors you get the same as \binom{}{b}, but the fact that b appears in the right place is just because of how TeX attempts error recovery for the missing \endgroup (that had already been absorbed and discarded in the process of expanding <CE>).

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.