Simplify \coordinate at parsing #785

[hmenke]

Motivation for this change

This is another attempt at fixing #785 to make the \coordinate at construction compatible with the (as of yet) internal \tikz@dcl@coord@ mechanism.

In some ways this is a quick and dirty fix because it doesn't remove the flaw of the original implementation of expecting a literal ( at the start of the coordinate. In principle the same as for \tikz@scan@one@point should be done which expands tokens until it finds a literal (.

Checklist

Please check the boxes to explicitly state your agreement to these terms:

• [x] Code changes are licensed under GPLv2 + LPPLv1.3c
• [x] Documentation changes are licensed under FDLv1.2

[hmenke]

Forgot to handle calc. In that case, I can also go the extra mile and loop over expansions.

[muzimuzhi]

In https://github.com/muzimuzhi/pgf/commit/0a2747ae85208ca6e62e368b67336fb38c092f14 I made an attempt to support a simplified \pgfextra (as simple as \pgfutil@firstofone) in node spec, so \coordinate at can eventually call

\tikz@fig ode[<options>] (<name>) \pgfextra{\def\tikz@fig@content{}} a

With the added detection for changed \tikz@fig@content in \tikz@fig@scan@at, #785 could be solved. Though I guess you're not a fan of this use of \pgfextra.

PS: I just realized \path coordinate and \node[coordinate] {<content>} are different. In order to auto insert {} at appropriate position, \path coordinate has a so strict/limited and not-yet-documented syntax. For example, foreach is not supported, and \coordinate (name) [...] at (coord) is not supported too.

[hmenke]

As always, thanks for your very insightful input. You are definitely right. We have to promote coordinate to a first class member of the syntax instead of rewriting it to \node[shape=coordinate] under the hood.