Hello Ihor,
thx for the follow-up! 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 - specify how to open the file (eg directly open it, or open a dired buffer with point on the file) - more generally, specify some code to run/action to perform after following the link 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. For example: say you want to open a file link in a specific manner (for example in dired) in response to a specific keystroke. 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. 2. About the org link format > One of the general ideas behind Org mode is that Org markup should be > human-readable. Agreed. > Using (:keyword value ...) syntax might also work. Maybe even dropping > outer parens - the idea is to get something similar to > attributes and header arguments: > [[file.txt:: :page 1 :highlight (0.24 0.47 0.33 0.49)]] That would work for me. I'm happy with anything that is easily readable and can store anything in a standardized way. > 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. > Rather we can allow web links specifically to follow their syntax and > parse it appropriately. Say, we can extend :search-option to be not just > a string, but also a plist, and parse it beyond file: link - in other > link types. It would make more sense to me to put such data in a metadata field as web link options can be quite general, eg, importing data into pdf form fields. Julien "Ihor Radchenko" <[email protected]> writes: > Julien Dallot <[email protected]> writes: > >> Based on what we discussed so far, here are some high-level guidelines we >> may want to follows: >> - we want to be able to include arbitrary metadata inside an org link (in >> plain text form) >> - we want to be able to store arbitrary metadata in the org element (once >> the link was parsed) >> - whenever possible, we want to follow web standards for links. > > I am not sold on storing metadata. > But we can certainly extend the existing notion of :search-option beyond > just file links. > > Currently, we support a number of search options using ad-hoc syntax > like > <file.txt::<line number>> > <file.txt::text to search> > <file.txt::/regexp/> > <file.txt::* headline search> > <file.txt::#id-search> > > Arguably, these options can be useful beyond file (and Org) links. > > One of the general ideas behind Org mode is that Org markup should be > human-readable. > > So, something like [[file.txt::line=<line number>]] would make a lot of > sense in my eyes. Or, more generally [[file.txt::keyword=value]]. > > Using (:keyword value ...) syntax might also work. Maybe even dropping > outer parens - the idea is to get something similar to > attributes and header arguments: > > [[file.txt:: :page 1 :highlight (0.24 0.47 0.33 0.49)]] > >> Based on those criteria, here is a possible alternative for the pdf >> link I presented at the beg of this thread: >> [[file:<path>#page=1#highlight=0.240196,0.478535,0.331699,0.494949]] >> and here is the "web-compatible" equivalent of current org link with >> ::<search-text> at the end: >> [[file:<path>#:~:text=<search-text>]] > >> The idea is that the link content (inside [[]]) is an (almost) working web >> link. > > 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. > > Rather we can allow web links specifically to follow their syntax and > parse it appropriately. Say, we can extend :search-option to be not just > a string, but also a plist, and parse it beyond file: link - in other > link types.
