I see the problem now thanks. I assume the existing regexp embedded into links avoid those ugly escapings using the fact that there is one and only one metadata (so just parse from "::/" to the end of the link "/]]" onward)
> The main question is how to deal with "...". And what about something > like (list 'foo) vs (foo). Or ?a vs 97. Let's first consider the simplest method (strictly from a programming pov): assume the metadata is just a plist that was escaped to fit into the link's syntax. If we do this, the other problems you mentionned are dealt with, as what we have in the :search-option after parsing the link is just a plist and hence whether the plist's properties are fully reduced are not is not important. > Do we want Elisp syntax or something simpler? Do you mean to allow another regexp syntax? or more generally to have the metadata listed as a more efficient syntax (python dictionnary or so)? Also, coming up with some special encoding to lighten the escapings looks like playing with fire, judged with my small knowledge on the matter of course. I personally would be in favor of just using plists and escaping twice if necessary. First because users do not look at link's internals often. Second because then the inner-working is very clear and easy to play with. For regexp for instance: if the property is a string then use it as a string, otherwise evaluate until you have a string (ie, rx or any custom function). "Ihor Radchenko" <[email protected]> writes: > Julien Dallot <[email protected]> writes: > >>> 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. > > No, because we do not need extra escaping related to "...". > >> However, that new format enables new possibilities. For instance, we >> could allow for rx expressions: >> [[::(:regexp (rx "(" "hello" ")"))]] > > The main question is how to deal with "...". And what about something > like (list 'foo) vs (foo). Or ?a vs 97. Do we want Elisp syntax or something > simpler?
