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:

• Code changes are licensed under GPLv2 + LPPLv1.3c
• 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 muzimuzhi@0a2747a 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.