While investigating an error executing a table formula I d= iscovered that cells containing '\$' cause column references to be e= xecuted even when no attempt is made to evaluate cell contents as code. Her= e's a simple example:

#+TITLE: demonstrate strange e= rror in currency column

| 3/1/2023 =C2=A0| Deposit =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| \$200.00 |
| 3/13/2023 | Interest= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | \$1.13 =C2=A0 |
| 4/1= /2023 =C2=A0| Deposit =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0| \$301.22 |
|-----------+------------------------+---------|
| =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | Number of Transactions | =C2=A0 =C2=A0 = =C2=A0 =C2=A0 |
#+TBLFM: @4\$3=3D'(length '(@1\$3..@I\$3))

Evaluating the table formula produces a 'Invalid f= ield specifier "\$200"' message. In more complicated examples = you just see a #ERROR in the cell. With formula debugging turned on, I can = evaluate the expanded expression with no errors.

T= his is surprising for a number of reasons:
1. The formula ma= kes no use of the cell contents
2. The formula debugger notes an error= but actually shows a valid expression
3. Columns with currencies will= be fairly common esp in imports from financial institutions
4. This e= rror happens before the formula is evaluated so there is no chance to remov= e the problem character in the formula as I do with the commas ',' = which are also present
Is this by design? If so, I=C2=A0was u= nable to find any documentation explaining it.

Thanks,
Jeff

--000000000000729d3505fbc2685c--