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.
--
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
