# tikz library shadows does not accept space

With TikZ library shadows, a space immediately after the curly bracket in drop shadow = { shadow... throws an error. If there is no space after the bracket, there is no error, i.e. drop shadow = {shadow... works. Is this a bug or is there a rationale behind the intolerance to space?

Package pgfkeys Error: I am the key '/tikz/ shadow xshift', to which
you passed '1ex', and I am going to ignore it. Perhaps you misspelled it.


MWE

\documentclass[border=10]{standalone}
\usepackage[svgnames]{xcolor}
\usepackage{tikz}
\tikzset{test1/.style = {drop shadow = { shadow xshift = 1ex}}}% test1 styles fail
\tikzset{
test2/.style = {% test2 styles work
},
}
}
\begin{document}
\begin{tikzpicture}
\fill[test1] (0,0) rectangle (1,1);
\end{tikzpicture}
\end{document}

• TikZ syntax generally is sensitive to spaces - it wants them or wants them not, for example. Sometimes, it is indifferent. But I don't see how you could call it a 'bug'. Is it really a problem? – cfr May 20 '16 at 21:05
• @cfr, I am not qualified to say if it might be a bug, a limitation or a feature by design. It seemed strange to me that line breaks and spaces were feasible just about everywhere (see test2) except in one place (see test1). It took me a good 15 minutes to locate the space I had intentionally placed, not knowing it could cause a problem. Also, the error message is sometimes quite scary, along the lines that the tikz shadow command is not recognized. – PatrickT May 20 '16 at 21:26
• As I understand it, it is probably more-or-less inevitable that the parser will sometimes be fussy because of the way in which arguments get bounced around, basically. There are certainly weirder cases than this ;). – cfr May 20 '16 at 22:21
• @cfr, I see! Perhaps you can make that an answer: give another example of a weird space-related situation we should be aware of? – PatrickT May 21 '16 at 11:02
• – cfr May 22 '16 at 0:16

In reply to @cfr's comment, I think this is a serious problem because people (at least me) love fancy indentation:

\tikzset{
test1/.style={
}
}
}


In such case, TikZ got redundant spaces inevitably because of new lines.

Unfortunately, this seems to be a deep bug of pgfkeys. Consider the following example

\documentclass[tikz]{standalone}
\tikzset{
option a/.style={
#1
}
}
\tikzset{
option b/.style={
option a={
#1
}
}
}
\tikzset{
option c/.style={
option b={
red
}
}
}
\begin{document}
\tikz\fill[          red ]circle(1);
\tikz\fill[option a={red}]circle(1);
\tikz\fill[option b={red}]circle(1);
\tikz\fill[option c      ]circle(1);
\end{document}


It produces two errors: One at option b={red}

I do not know the key '/tikz/ red '


And the other at option c:

I do not know the key '/tikz/  red  '


One can accumulate spaces as follows

\documentclass[tikz]{standalone}
\tikzset{option a/.style={ #1 } }
\tikzset{option b/.style={option a={ #1 } } }
\tikzset{option c/.style={option b={ #1 } } }
\tikzset{option d/.style={option c={ #1 } } }
\tikzset{option e/.style={option d={ #1 } } }
\tikzset{option f/.style={option e={ #1 } } }
\tikzset{option g/.style={option f={ #1 } } }
\tikzset{option h/.style={option g={ #1 } } }
\tikzset{option i/.style={option h={ #1 } } }
\tikzset{option j/.style={option i={ #1 } } }
\tikzset{option k/.style={option j={ #1 } } }
\begin{document}
\tikz\fill[option k=red]circle(1);
\end{document}

 I do not know the key '/tikz/          red          '


# A partial solution

This trick is so fragile that if one replace } } } by }} } or } }}, the corresponding spaces disappear.

Probably this is the why the source code of TikZ contains so many lonely %. For instance tikz.code.tex line 1209-1215

\tikzset{
no marks/.style={mark=none},%
no markers/.style={mark=none},%
every mark/.style={},
mark options/.style={%
every mark/.style={#1}%
}}


# Appendix

drop shadow is defined in tikzlibraryshadows.code.tex

\tikzset{

Here, general shadow is option a, drop shadow is option b, and test1 is option c.