Re: strange behaviour with $PROP_r1 value in a table

[Ihor Radchenko <yantar92@posteo.net>]

Rens Oliemans <hallo@rensoliemans.nl> writes:

>>> -    (while (string-match "\\<\\([a-zA-Z]+\\)\\([0-9]+\\>\\|&\\)\\|\\(;[^\r\n:]+\\|\\<remote([^,)]*)\\)" s start)
>>> +    (while (string-match "\\(\\$PROP_\\)\\{0\\}\\<\\([a-zA-Z]+\\)\\([0-9]+\\>\\|&\\)\\|\\(;[^\r\n:]+\\|\\<remote([^,)]*)\\)" s start)
>>
>> This is doing much more than fixing the reported bug and might affect
>> valid uses. I'd rather fix the bug (if it is a bug) explicitly, without
>> risking breaking other things.
>
> Hm, looking at the manual ("(org) References"), a constant of the form '$PROP_Xyz' will be
> used to search for property 'Xyz', and it seems like a bug to convert 'Xyz' to another
> format in this case.
>
> The only use-cases that are affected with this change seem to be when a table formula
> starts with '$PROP_' and has a spreadsheet-like reference after it, no? Perhaps I am
> wrong: I searched for the usages of `org-table-convert-refs-to-rc', but perhaps I missed
> something important.

Another potential example is
#+CONSTANTS: valC2=299792458.
and then $valC2 reference.

> Do you agree that it is a bug, even with `org-table-use-standard-references' set to `t' or
> `from'?

Currently, the order of reference expansion is undefined. So, it is
_technically_ not a bug, but undefined behavior.

However, it is indeed confusing.
So, we may consider specifying the order of reference expansion.
But what should be that order? We need to think about all possible
expansions and how they might interact in edge cases (e.g. what if we
have :CrazyPropertyName@1$2:)

Also, it is confusing that the manual does not clearly explain that "B4"
expansion only happens when editing formulas interactively via formula
editor.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>