Hello back,
I've been thinking and it may be great to also have a retrocompatibility keyword, like: [[file:<path>::(:versatile-search "/<regexp>/")]] which would be evaluated just like current links: [[file:<path>::/<regexp>/]] This is because we may want to have the power of new keywords still act on old links. Here is my use case. I can open a link in different manners depending on the keystroke I use to open it, eg, normal openning vs open a dired buffer with point on the linked file. I believe the clean way to do that is to describe the desired opening method directly inside the parsed org-element. For instance: (:search-option (:opening-method 'dired-buffer)) Then here is what would happen when I open a link in the "dired" way: parse the link, insert ":opening-method 'dired-buffer" inside the :search-option property of the parsed org-element, finally call normal org-link-open function. Of course it only works if the :search-option property contains a plist. Now if it is not a plist, we can make one and store whatever was there in the :versatile-search property (insert a better name there). Julien "Julien Dallot" <[email protected]> writes: >> So, it is an implicit nil, or empty string for the purposes of the link >> (we should have no notion of nil in there) > > Empty string sounds good. After some thoughts I find logical to assume > that the user meant the empty string if no data was provided. > > > "Ihor Radchenko" <[email protected]> writes: > >> Julien Dallot <[email protected]> writes: >> >>>> #+begin_src emacs-lisp :noweb is test >>>> #+end_src >>>> >>>> interpreted as (:noweb "is test"), simply splicing the value by :keyword >>>> (unless :keyword is inside "..."). >>> That looks good to me. Especially if it is already in use. >>> >>> There are some edge cases that should be taken care of. >>> Like, what if the second word starts with a ":"? Then we should >>> treat it as a normal keyword (since it may be used by some >>> third-party package). But then, we cannot simply parse a link like >>> [[::(:id wrong :syntax :regexp foo)]] >>> as a plist, as this would result in >>> (:id "wrong" :syntax :regexp "foo") >>> which is an invalid plist since all properties must have a value >>> (this problem also applies if we want to give a property the empty >>> string without "...") >>> >>> Then not sure what to do. We could fill the gap with an empty string: >>> (:id "wrong" :syntax "" :regexp "foo") >>> or remove the :syntax part altogether: >>> (:id "wrong" :regexp "foo") >> >> If we continue the analogy with src blocks, >> >> #+begin_src emacs-lisp :noweb is :comments :eval yes >> #+end_src >> >> will yield (via org-babel-get-src-block-info) >> >> ((:noweb . "is") (:comments) (:eval . "yes")) >> >> So, it is an implicit nil, or empty string for the purposes of the link >> (we should have no notion of nil in there)
