thanks Max and Christian for your insights.
about the separator: > The =::= separator is already in use for line numbers, text search, > headline names, custom IDs and code references. Its use for metadata > additions would not be generalizable to 'file:' and 'id:' links where > this search syntax is useful. In bespoke link types like the one Julien > shows here, one can do whatever one likes. But a candidate Org syntax for > link properties, if we want one, should probably use a different > separator. Agreed. Such additional metadata could then be stored in an org element object simply with an additional ":metadata" field (like the ":search" field currently used for everything that follows "::"). I dont know of strong guidelines for the choice of such a separator, except for common sense ones. I see that ":~:" is used in the link Max shared, that may be a good idea then (https://developer.mozilla.org/en-US/docs/Web/URI/Reference/Fragment, it's used in the link that max pointed out to start highlighting text links). On the use for arbitrary metadata: > Although Julien's 'pdf:' link uses these added properties for the same > purpose as the search syntax (identifying a document fragment), that's > not the only purpose that link metadata might be useful for. To take my > web link example, an enhanced 'file:' link might take properties like > (:attr_html (:title My contact info :rel me)) and add them as HTML > attributes when publishing to web. That would be orthogonal to the > purpose of pointing to a document fragment, and one might want use both > at the same time. That's a use case, and I see (and use) many others (reliable search for ids, opening a music or a video at a specific time stamp). As Max noted, it may be possible to use a syntax compatible with url links. For instance using the notation defined in the shared documentation: - with #t=<timestamp> to open a video at a specific timestamp for instance - with "#xywh=<coordinates>" for highlighting a given area in a pdf (and not to search text, which is less reliable). The only downside I see (compared to using plist) is about clarity/readability. Links created with such systems intentionally have no white spaces and are therefore hard to parse for a human. But that may not be relevant for our purpose. Otherwise, I only see arguments in favor of adopting that system, and I'd be up to try it. I may miss something obviously. The best point would be that many links that work locally could be open directly in a browser, eg, same notation to open a local or youtube video at a given timestamp. Julien "Christian Moe" <[email protected]> writes: > Max Nikulin <[email protected]> writes: > >> On 09/06/2026 2:23 pm, Julien Dallot wrote: >>> I feel like the format with a plist inside the link is simple and >>> understandable enough, while enabling to encode pretty much anything. >> >> I find the idea of plist in links as interesting, however, I am >> afraid, it has no chance to be adapted outside of Emacs. I strongly >> believe that it should be easy to send links to friends and >> colleagues. So, if possible, I would stick to existing URL >> conventions. Some formats have documented ways to specify document > > +1, and as Max points out, that applies to PDFs. > > But there are other potential uses for adding properties to a link for > which there are no URL solutions, such as adding html attributes to an > ordinary web link. With such potential uses in mind, I think that > Julien's question about representing arbitrary metadata is interesting > to discuss, but that the proposed syntax has a drawback: > >> [[pdf:<path>::(:page 12 :edges (0.240196 0.478535 0.331699 0.494949))]] > > The =::= separator is already in use for line numbers, text search, > headline names, custom IDs and code references. Its use for metadata > additions would not be generalizable to 'file:' and 'id:' links where > this search syntax is useful. In bespoke link types like the one Julien > shows here, one can do whatever one likes. But a candidate Org syntax for > link properties, if we want one, should probably use a different > separator. > > Although Julien's 'pdf:' link uses these added properties for the same > purpose as the search syntax (identifying a document fragment), that's > not the only purpose that link metadata might be useful for. To take my > web link example, an enhanced 'file:' link might take properties like > (:attr_html (:title My contact info :rel me)) and add them as HTML > attributes when publishing to web. That would be orthogonal to the > purpose of pointing to a document fragment, and one might want use both > at the same time. > > Regards, > Christian
