> 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. > 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. Julien "Ihor Radchenko" <[email protected]> writes: > Julien Dallot <[email protected]> writes: > >>> I do not like :metadata because it gives temptation to store something >>> unrelated to opening the link itself. We have seen enough abuse of links >>> in Org, so I do know that people will get creative. At least, we can >>> hint that the purpose is :search-option, not something else. >>> It is simply a naming question, I think. >>> Otherwise, there is no difference. > >> Sounds good to me! >> I was afraid doing this may add additional complexity as this tempers with >> existing norms. >> But that works for me. > > Having a link like <file:foo.org::(:line 10)> will be breaking no matter > what. So, if we accept that we are going to make a breaking, change, I > prefer to stick to and expand existing conventions. > >> So a proposal could be: >> 1. About link format (in plain text): >> Enable to add arbitrary metadata in a plist format after the "::" symbol. >> Some keywords could be buil-in. e.g.: >> - :text, :regexp, :id , :line , :sh (i.e., enable to re-express the search >> options that were already possible without the plist format) >> - :highlight and :page to specify a given page and region to highlight in a >> pdf (I think I'll issue a merge request to the author of pdf-tools for that) > > Yes. > >> 2. About the org element after the link was parsed >> While the link is parsed, detect whether the metadata is in a plist format >> or not. If not run the existing code. If yes, then put in the :search-option >> property the parsed plist. >> The decision of whether the metadata is a plist or not could come in >> two steps: first recognize a special characted right after the "::", >> i.e., a "(" or a whitespace, then extract the plist and check that >> it's indeed a plist (run plistp). > > 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. > > 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? > >>> That will create problems like potential clashes with other AST >>> properties ([[file:foo.org:: :begin "break the parser!"]]). >>> I'd rather keep everything inside :search-option to be safe. > >> Why is :begin breaking the parser here? >> The org maintainers get to choose which words are built-in, so the rule of >> thumb could be to respect web links norms as much as possible. > > My understanding of what you proposed was making the parser parse > [[file:foo.org:: :keyword value]] as > (link (... :keyword value) ...) > But then :keyword may clash with existing parser properties. > >>> Have you heard about file+sys and file+emacs syntax? > >> I did not, and they are not part of the org documentation afaict. Actually I >> could not find what those are for in forums, users just advise people to >> forget about those and treat it as normal links. >> I'm wondering what you (or anyone else) think about what the cleanest way to >> open a link with custom behavior is? > > Well. They are obsolete :) > I know them because they are still in the code. > > *** ~file+emacs~ and ~file+sys~ link types are deprecated > > They are still supported in Org 9.0 but will eventually be removed in > a later release. Use ~file~ link type along with universal arguments > to force opening it in either Emacs or with system application.
