4

I don't get space-observing look-aheads right. What am I doing wrong here?

\documentclass{article}
\usepackage{expl3}
\begin{document}
\ExplSyntaxOn
\cs_new_protected:Npn \testInNormalLaTeXSyntax #1
  { \intern: #1 }
\cs_new_protected:Nn \intern:
  {
    \peek_charcode:NTF A
      { (next~token~is~A)~ }
      { 
        \peek_charcode:NTF ~
          { (next~token~is~space)~ }
          { (next~token~is~neither~nor)~ }
      }
  }
\ExplSyntaxOff

Hello, world with spaces!\\
\testInNormalLaTeXSyntax{AA}\\
\testInNormalLaTeXSyntax{bA}\\
\testInNormalLaTeXSyntax{ A}
\end{document}

White the first test works (AA), but the code line \peek_charcode:NTF ~ breaks things.

2
  • 2
    That is the exact same thing as writing \foo so the spaces is “gobbled”. May be you want \c_space_token?
    – Manuel
    Sep 13, 2014 at 20:00
  • @Manuel, that's it! I was thinking so complicated and the answer was so simple. Make your comment an answer and I'll tick it.
    – mh543
    Sep 13, 2014 at 20:34

1 Answer 1

4

That ~ is nothing more than a space, and it works exactly like always: \foo \bar is the same as \foo\bar

In that case what you are looking for is \c_space_token, which is a stored space token, thus

\peek_charcode:NTF \c_space_token 

should work.

5
  • 1
    Perhaps not that ~ is specifically excluded from being an N-type argument
    – Joseph Wright
    Sep 13, 2014 at 21:00
  • @JosephWright I'm not sure what do you mean… It's not “specifically excluded” but “generally excluded” (as any space token after a control sequence), or you mean something different? If you want a tokenized space you need something like, e.g., \use:nn { \token_new:NN \c_space_token } { ~ }.
    – Manuel
    Sep 13, 2014 at 22:31
  • 1
    Spaces (~) and grouping braces ({ and }) are not N-type arguments and so should never be expected to work as such. That's the reason that we have \peek_after:Nw and \exp_after:wN and not :NN signatures, for example. So \use:nn { \token_new:NN \c_space_token } { ~ } is still formally forbidden, even though it would work at present.
    – Joseph Wright
    Sep 14, 2014 at 7:11
  • Okey, I understood. N are never {, } or ~ (space), in case those will be expected in an argument, that argument will be w. Then \cs_set_eq:NN doesn't need the =~ but only = in its definition. And \token_new:NN should be \token_new:Nw, shouldn't it?
    – Manuel
    Sep 15, 2014 at 16:33
  • I raised the business about \cs_set_eq:NN with the team. Position there is simple: only N-type args are allowed, and the =~ in the definition is something that might change. On \token_new:NN, the entire token module is a bit of a mess: we haven't yet got to a point where we know what is really needed! I'd say 'expect changes'.
    – Joseph Wright
    Sep 15, 2014 at 16:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .