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. -- 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>
