> I am not sure if it is simple.
> Consider the classic Elisp regexp plague inside "...".
> We need monstrosities like "\\\\(...\\\\)". Now, imagine we put a regexp
> inside a link:
>
> [[::(:regexp "\\\\\\\\(...\\\\\\\\)")]] ?
Isnt there the same problem for current regexp search embedded in links? I do
not see a problem that could arise from putting whatever regexp we used to have
in this new format.
However, that new format enables new possibilities. For instance, we could
allow for rx expressions:
[[::(:regexp (rx "(" "hello" ")"))]]
"Ihor Radchenko" <[email protected]> writes:
> Julien Dallot <[email protected]> writes:
>
>>> There is one potential clash:
>>>
>>> [[(coderef)]] links may be confused with the proposed syntax, especially
>>> if we also want to allow its variant without file name.
>>
>> Always starting metadata with "::" looks simple enough and effective.
>
> +1
>
>>> Also, so far, we refrained from specifying link internals in the syntax
>>> spec in https://orgmode.org/worg/org-syntax.html
>>> This proposal calls for more details, but the question is then how we
>>> specify the (...) syntax. Should we refer to Elisp with all its escape
>>> rules? Should we use something simpler?
>
>> I was thinking about this simple process.
>> To come up with a plain text link, start with the target plist (the
>> one that should be stored in the :search-option property of the org
>> element).
>> Then apply classic escape rules on this (so "]" -> "\]" and "\" -> "\\").
>> It seems enough and simple to me, but I may miss smth from your comment.
>
> I am not sure if it is simple.
> Consider the classic Elisp regexp plague inside "...".
> We need monstrosities like "\\\\(...\\\\)". Now, imagine we put a regexp
> inside a link:
>
> [[::(:regexp "\\\\\\\\(...\\\\\\\\)")]] ?
