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