> So, are you saying that we should always write something like > > <::(:id "id-value")>? > why not simply > <::(:id id-value)>? I think escaped plist with string values should be the default that "always works for sure". Though we could have special treatment for values whitout "..." and assume they do not contain a white space. >From that point of view, it seems the best way to interpret a link like <::(:id id value :regexp foo)> would be to simply ignore the "value" part of the :id property.
>> So >> <::(:id "foo\nbar")> >> should be >> <::(:id "foo\\nbar")> > > But what will that mean? How should id be interpreted? > Should the value be foo\nbar verbatim, or should \n expand to newline? It should be foo\nbar verbatim. In the end, it just becomes a string stored in a plist in the :search-option property of the org element. > But what will that mean? How should id be interpreted? > Should the value be foo\nbar verbatim, or should \n expand to newline? "Ihor Radchenko" <[email protected]> writes: > Julien Dallot <[email protected]> writes: > >> Those would be all invalid. Our method requires that the metadata is >> a properly escaped plist such that properties like :id, :regexp >> ... have string values. > > So, are you saying that we should always write something like > > <::(:id "id-value")>? > why not simply > <::(:id id-value)>? > >> So >> <::(:id "foo\nbar")> >> should be >> <::(:id "foo\\nbar")> > > But what will that mean? How should id be interpreted? > Should the value be foo\nbar verbatim, or should \n expand to newline? > >>> and what about >>> >>> <::(:id "foo\"bar" invalid??)> >> That would be obviously invalid as well, not sure I get what you meant here. > > Not obviously. We may, for example, ignore the "invalid??" part. > Or treat it as a pair of values: :id -> foo\"bar + invalid?? -> nil
