> 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.
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)
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).
> 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.
> 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?
Julien
"Ihor Radchenko" <[email protected]> writes:
> Julien Dallot <[email protected]> writes:
>
>> 1. About storing metadata in org elements.
>>> I am not sold on storing metadata.
>>> But we can certainly extend the existing notion of :search-option beyond
>>> just file links.
>
>> Storing everyting in the :search-option property is a possibility, and it
>> would work for my current workflow.
>
>> I'm mostly wondering why NOT to have a dedicated :metadata property. As
>> there could exist sensible workflows with metadata that are typically not
>> search options.
>> For instance:
>> - specify a highlighting color for the pdf region to highlight
>> - more generally, specify some code to run/action to perform after following
>> the link
>> - specify how to open the file (eg directly open it, or open a dired buffer
>> with point on the file)
>
>> I would see multiple good points about this:
>> - it avoids confusions since some metadata may not be search options
>> - easy implementation and backward compatibility
>> - smoother link customization: as of now (as far as I know), there is no
>> clean, "canonical" way to pass extra arguments when opening a link.
>
> 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.
>
>> As of now, the normal way to do it (again, afaik) is to create your
>> own function that does it for you. Problem is, this bypasses normal
>> org link opening (and potential hooks that come with it, eg, path
>> correction from linkin-org).
>> A simple way out is the following: when opening the link with the
>> specific keystroke, also add a (:opening-method 'file-browser)
>> property inside the org element, and then call the normal org link
>> functions.
>
> Have you heard about file+sys and file+emacs syntax?
>
>>> I do not think that we should aim for such compatibility.
>>> Web links are not very human-readable, and Org mode tries to be
>>> human-readable.
>> Going back to a previous message, an intermediate idea would be to
>> name the org link properties as web links keywords whenever possible
>> to allow simple translation between org links and web links.
>
> 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.
