是否可以为 Tikz 路径?节点生成上下文无关语法?

是否可以为 Tikz 路径?节点生成上下文无关语法?

甚至,我很高兴看到 tikz 语言的定义与 Java 和 Pascal 等编程语言的通常定义方式一样。

我之所以问这个问题,是因为我总是因为最细微的拼写错误而收到神秘的错误消息。本质上,底层语言的错误使用会导致编译器“崩溃”。这种崩溃有时会给出有用的错误消息,但有时很难解读。

答案1

给出一个非 CS 答案:如果没有另一个完整的前端来实现语法修复

TikZ 的实际机制本质上\pgfutil@ifnextchar大致如下:检查下一行并决定做什么

一个很好的例子是

\def\tikz@lineto{%
  \pgfutil@ifnextchar |%
  {\expandafter\tikz@hv@lineto\pgfutil@gobble}%
  {\expandafter\pgfutil@ifnextchar\tikz@activebar{\expandafter\tikz@hv@lineto\pgfutil@gobble}%
    {\expandafter\tikz@lineto@mid\pgfutil@gobble}}}
\def\tikz@lineto@mid{%
  \pgfutil@ifnextchar n{\tikz@collect@label@onpath\tikz@lineto@mid}%
  {%
    \pgfutil@ifnextchar c{\tikz@close}{%
      \pgfutil@ifnextchar p{\tikz@lineto@plot@or@pic}{\tikz@scan@one@point{\tikz@@lineto}}}}}
\def\tikz@lineto@plot@or@pic p{%
  \pgfutil@ifnextchar i{\tikz@collect@pic@onpath\tikz@lineto@mid p}{%
    \pgfsetlinetofirstplotpoint\tikz@plot}%
}

现在让我们选择c下一个参数。我们可以看到它在 if 情况下进出,丢弃不,它不是|,那么它一定是-.所以它已经没有任何可能性了假设。现在我们看到了这一点,我们就可以开始捣鼓它了

\begin{tikzpicture}
\draw (0,0) -x (1,1);
\draw (0,0) -! (1,1);
\draw (0,0) -@ (1,1);
\end{tikzpicture}

是的,它们都有效。我认为,这种灵活性的原因不是上下文无关语法,而是为未来的实现留下了开放的余地。还有更多这样的插槽;例如hobbycontrols图书馆很好地侵入了关键字。

好的,假设它确实--在上一步中,并且下一个字符是c。现在我们再次进行解析。我们检查是否有以 n 开头的内容,如果不是,那么就是c

\def\tikz@close c{%
  \pgfutil@ifnextchar o{\tikz@collect@coordinate@onpath\tikz@lineto@mid c}% oops, a coordinate
  {\tikz@@close c}}%

从注释中可以看出,它希望找到cyclecoordinate。如果它确实是一个坐标,它就必须通过这个 TeX 障碍

\def\tikz@collect@coordinate@onpath@#1oordinate{%
  \pgfutil@ifnextchar[{\tikz@@collect@coordinate@opt#1}{\tikz@@collect@coordinate@opt#1[]}}%}

如果你在 上有拼写错误coordinate,比如说,

\begin{tikzpicture}
\draw (0,0) -x (1,1) cordinate (a);
\end{tikzpicture}

你得到的错误Use of \tikz@cosine doesn't match its definition是 TeX 错误,TikZ 没有权限处理。而且这个错误确实非常神秘,你在跟我开玩笑吗,不管怎样,谁要求的cosine 1

所以我的论点是 TikZ 的成功让我们误以为 TeX 的繁琐宏等已经消失,并且 TikZ 更加宽容。事实并非如此。TikZ 最大的问题是没有安全的选项可以回退。在解析机制的任何一点,只有正确的分支才能产生有意义的 PGF 语法字符串,这是一个非常严格的规范。所以我不会把钱押在可能性上,但你永远不知道。有很多聪明人在那里。


1(顺便说一下,这是我跳过的另一个开关,它检查后面的字母co,如果不能分支则假设余弦)

相关内容